Вопрос по тяжелым математическим вычислениям в Java

Question

Я использую Java в своем проекте, который выполняет много математических вычислений. На следующей итерации проекта будут добавлены еще некоторые расчеты. Из моего знания Java я подозреваю, что это вызовет проблемы с производительностью. Является ли разумным решение делегировать тяжелые вычисления на язык низкого уровня, такой как Fortran или C? Я могу запускать родные звонки, чтобы общаться с языками низкого уровня. Java возьмет на себя управление, как только вычисления будут выполнены Fortran или C. Будет ли это лучше производительность?

Answer 1

Будьте осторожны, чтобы не недооценивать современные виртуальные машины Java. Первое поколение было невероятно медленным, особенно в арифметике с плавающей точкой, но современные действительно очень быстрые.

Сказав это, другие варианты, вероятно, будут быстрее.

Конечно, вы должны запустить несколько тестов. Не думайте, что одно будет быстрее другого, проведите конкретные измерения производительности и примите решение на этой основе.

Также подумайте, стоит ли дополнительная производительность (если таковая имеется) «нативного» решения, чтобы не было лишних хлопот с его написанием и интеграцией.

Answer 2

Целочисленная математика и математика с плавающей точкой как таковая в Java передаются непосредственно аппаратному обеспечению, и вычисления как таковые в принципе не медленнее, чем, скажем, в C или FORTRAN. Библиотечные процедуры для таких вещей, как трансцендентные функции (sin(), sqrt(), log() и т. Д.) На самом деле реализованы на C, поэтому, опять же, нет веских оснований искать другие библиотеки.

Есть некоторая информация, которую я хотел бы, чтобы ваш вопрос дал нам. Вы упомянули, что идет много вычислений, и это хруст числа. Но вы ничего не говорите нам о том, как эти номера организованы и доступны. Это, наверное, интересная и полезная информация. Если вы используете сложные объектные структуры для хранения ваших данных, доступ к этим структурам займет время. Если ваши результаты создают новые объекты, это тоже дорого. Если вы используете массивы, это тоже объекты. Многомерные массивы в Java - это массивы массивов, и индексирование по нескольким измерениям может разрешить ссылки на объекты, которые работают медленнее, чем в других языках. Хотя у меня нет тестов, чтобы доказать это, я подозреваю, что вам лучше заменить многомерные массивы на одномерные и немного «ручного» расчета индекса. Вам, безусловно, лучше использовать массивы фиксированного размера, возможно, с небольшим провалом, а не создавать и отбрасывать новые массивы для каждого вычисления. Наконец, многие из объектно-ориентированных приемов, делающих структуру вашей программы более «элегантной» и «гибкой», имеют тенденцию вносить много ненужной объектной ориентации с сопутствующими замедлениями. Примитивно, но просто, как правило, быстрее.

Очень простая оптимизация может состоять в том, чтобы просто использовать опцию -server вашей JVM (если она доступна), чтобы получить выгоду от дополнительной предварительной компиляции, если вы этого еще не сделали.

Я рекомендую другим людям, чтобы вы профилировали свои расчеты, прежде чем приступить к слепой ре-архитектуре своей программы. В удивительных местах могут быть узкие места.

Answer 3

Можете ли вы подумать об использовании параллельных алгоритмов.Это может или не может быть применимо в вашем случае, но подумал об этом.

Answer 4

Все комментарии пока превосходны.Я бы согласился, что нативный код должен быть последним шагом.

Распараллеливание стоило бы изучить.

То же самое, если использовать другой алгоритм, в зависимости от того, что вы делаете.

Никто не предлагал вам профилировать код, чтобы узнать, на что тратится время.Прежде чем приступать к каким-либо изменениям, я бы получил некоторые данные, чтобы точно узнать, что и где делается.Он будет руководить вашими решениями лучше, чем угадывать.

Answer 5

Вы также должны играть с различными параметрами виртуальной машины.Запустите вашу программу в режиме сервера, таким образом JIT произведет лучший код, поэкспериментирует с различными сборщиками мусора, включит escape-анализ (может быть, лучше использовать JDK 7 с этим).

Эта статья может помочь вам настроить вашу программу на использование лучших из JVM.

Если вы решите выбрать собственный путь, используйте JNA, это будет намного проще, особенно если все ваши вычисления будут в одном вызове метода.

Answer 6

Это зависит от двух факторов:

1. Следует помнить, что вызовы JNI будут стоить.Если вы можете получить весь свой расчет до C, эти накладные расходы могут стать незначительными, и вы можете получить некоторую производительность.В противном случае, если вы собираетесь переключаться между C и Java, у вас не будет шансов улучшить свою производительность.расчет.Сначала вы должны определить, действительно ли производительность, которую вы можете получить от C, действительно выше, чем в Java.Я смутно припоминаю некоторую статью по тестированию C и Java, в которой фактически утверждалось, что Java лучше справляется с математическими вычислениями.Но в любом случае я бы оценил оба - по крайней мере, их подмножество.

Answer 7

Остерегайтесь типов обертки. Для производительности вам лучше использовать примитивные типы, так как упаковка и распаковка занимает циклы процессора и обременяет сборщик мусора. Особенно в коллекциях коробочных значений много накладных расходов. Для коллекций я бы использовал примитивные массивы или байтовый буфер с точки зрения производительности.

Answer 8

Я бы посоветовал подождать и посмотреть ... Внедрить в Java как обычно, а затем измерить производительность, хорошо это, приемлемо или плохо?

Как сказал Скаффман, современные виртуальные машины JVM обладают высокой производительностью, и спасибодля JIT-компилятора они во многих случаях быстрее , чем собственный C.

В этой статье показаны некоторые сравнения между вычислениями Java и C, это также пример использованияпоследняя версия JVM - хорошая идея с точки зрения производительности.