Производительность математических библиотек Java? [закрыто]

Построение на сообщении Varkhan, что определенный для Pentium собственный код добился бы большего успеха:

• jBLAS: этапный альфой проект с обертками JNI для Атласа: http://www.jblas.org .

  • сообщение в блоге Автора: http://mikiobraun.blogspot.com/2008/10/matrices-jni-directbuffers-and-number.html .

• MTJ: Другой такой проект: http://code.google.com/p/matrix-toolkits-java/

Вы смотрели на Математическая Библиотека Ядра Intel ? Это утверждает, что превзошло по характеристикам даже ATLAS. MKL может быть используется в Java через обертки JNI.

Мы использовали КОЛЬТ для некоторых довольно больших серьезных финансовых вычислений и были очень довольны им. В нашем в большой степени представленном коде мы почти никогда не должны были заменять реализацию КОЛЬТА одним собственным.

В их собственном тестировании (очевидно весьма зависимом), я думаю, что они требуют в факторе 2 из Intel оптимизированных рукой ассемблерных стандартных программ. Прием к использованию его хорошо удостоверяется, что Вы понимаете их принципы проектирования и избегаете постороннего объектного выделения.

Код Linalg, который полагается в большой степени на Pentiums и векторные вычислительные возможности более поздних процессоров (запускающийся с расширений MMX, как LAPACK и теперь Атлас BLAS) "фантастически не оптимизирован", но просто промышленный стандарт. Для тиражирования той производительности в Java, Вы испытываете необходимость в собственных библиотеках. У меня была та же проблема производительности, как Вы описываете (главным образом, чтобы смочь вычислить разложения Choleski) и ничто не нашли действительно эффективным: Jama является чистым Java, так как он, как предполагается, просто шаблон и ссылочный набор для реализаторов для следования..., которого никогда не происходило. Вы знаете математическое свободное городское население Apache... Что касается КОЛЬТА, я должен все еще протестировать его, но это, кажется, полагается в большой степени на улучшения Ниндзя, большинство которых было достигнуто путем создания специального компилятора Java, таким образом, я сомневаюсь, что это собирается помочь. В той точке я думаю, что нам "просто" нужно коллективное усилие создать собственный компонент реализация Jama...

Я не могу действительно прокомментировать определенные библиотеки, но в принципе существует мало причины таких операций, чтобы быть медленнее в Java. Горячая точка обычно делает виды вещей, которые Вы ожидали бы, что компилятор сделает: это компилирует основные математические операции на переменных Java к соответствующим машинным командам (это использует инструкции SSE, но только один на операцию); доступы к элементам массива компилируются для использования "необработанных" инструкций MOV, как Вы ожидали бы; это принимает решения о том, как выделить переменные регистрам, когда это может; это переупорядочивает инструкции использовать в своих интересах архитектуру процессора... Возможное исключение - то, что, поскольку я упомянул, Горячая точка только выполнит одну операцию на инструкцию SSE; в принципе у Вас могла быть фантастически оптимизированная матричная библиотека, которая выполнила несколько операций на инструкцию, хотя я не знаю, делает ли, скажем, Ваша конкретная библиотека FORTRAN так или если такая библиотека даже существует. Если это делает, в настоящее время нет никакого пути к Java (или по крайней мере, Горячая точка) для конкуренции с тем (хотя Вы могли, конечно, записать свою собственную собственную библиотеку с теми оптимизациями для вызова от Java).

Поэтому, что все это означает? Хорошо:

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

, помеха А для операций над матрицей часто является проблемами местности данных, которые возникают, когда необходимо пересечь и строку строкой и столбец столбцом, например, в умножении матриц, так как необходимо хранить данные в порядке, который оптимизирует один или другой. Но если Вы пишете от руки код, Вы иногда можете операции объединения для оптимизации местности данных (например, если Вы умножаете матрицу на ее преобразование, можно превратить обход столбца в обход строки, если Вы пишете специализированную функцию вместо того, чтобы комбинировать две библиотечных функции). Как обычно, в жизни, библиотека даст Вам неоптимальную производительность в обмен на более быструю разработку; необходимо решить, как важная производительность Вам.