Les performances de Java matrice bibliothèques de mathématiques?

Question

Nous sommes le calcul de quelque chose dont l'exécution est liée par des opérations matricielles. (Quelques détails ci-dessous si vous êtes intéressé.) Cette expérience nous a amenés à la question suivante:

Ne folkloriques ont de l'expérience avec les performances des bibliothèques Java pour la matrice de mathématiques (par exemple, multiplier, inverse, etc.)? Par exemple:

• JAMA
• COLT
• Apache commons mathématiques

J'ai cherché et rien trouvé.

---

Détails de notre système de comparaison de la vitesse:

Nous sommes à l'aide d'Intel FORTRAN (ifort (IFORT) 10.1 20070913). Nous avons ré-implémenté en Java (1.6) à l'aide d'Apache commons mathématiques 1.2 matrice de la fpo, et il convient à tous ses chiffres de précision. (Nous avons des raisons pour vouloir en Java.) (Java doubles, Fortran real*8). Fortran: 6 minutes, Java 33 minutes), de même machine. jvisualm profilage montre beaucoup de temps passé dans RealMatrixImpl.{getEntry,isValidCoordinate} (qui semblent avoir disparu d'inédits Apache commons mathématiques 2.0, mais le 2.0 n'est plus rapide). Fortran est l'aide de l'Atlas routines BLAS (dpotrf, etc.).

Évidemment, cela dépend de notre code dans chaque langue, mais nous pensons que la plupart du temps, c'est l'équivalent de la matrice des opérations.

Dans plusieurs autres calculs qui n'impliquent pas de bibliothèques, Java n'a pas été beaucoup plus lent, et parfois beaucoup plus rapide.

Answer 1

Je suis l'auteur de Java de la Matrice de Référence (JMatBench) et je vais vous donner mes pensées sur cette discussion.

Il y a de différence significative entre les bibliothèques Java et alors qu'il n'y a pas de gagnant clair dans l'ensemble des opérations, il y a quelques des chefs comme on peut le voir dans les derniers résultats de la performance (octobre 2013).

Si vous travaillez avec des "grands" matrices et peuvent utiliser des bibliothèques natives, puis le gagnant clair (3,5 x plus rapide) est MTJ avec système optimisé netlib. Si vous avez besoin d'un pur Java solution, alors MTJ, OjAlgo, EJML et Parallèle Colt sont de bons choix. Pour les petites matrices EJML est le gagnant clair.

Les bibliothèques je n'ai pas mentionné a montré des problèmes de performances ou manquantes principales caractéristiques.

Answer 2

Juste pour ajouter mon 2 cents. Je l'ai comparée à certaines de ces bibliothèques. J'ai essayé de multiplier une matrice 3000 de 3000 de la matrice de doubles de lui-même. Les résultats sont comme suit.

À l'aide de multithread ATLAS avec C/C++, Octave, Python et R, le temps était d'environ 4 secondes.

À l'aide de la Jama avec Java, le temps était de 50 secondes.

À l'aide de Colt et Parallèle Colt avec Java, le temps était de 150 secondes!

À l'aide de JBLAS avec Java, le temps était à nouveau autour de 4 secondes JBLAS utilise multithread ATLAS.

Donc, pour moi, il était clair que les bibliothèques Java de ne pas effectuer trop bien. Toutefois, si quelqu'un a un code en Java, alors la meilleure option est JBLAS. Jama, Colt et Parallèle Colt ne sont pas rapides.

Answer 3

Je suis l'auteur principal de jblas et tenais à préciser que j'ai publié la Version 1.0 à la fin de décembre 2009. J'ai beaucoup travaillé sur l'emballage, ce qui signifie que vous pouvez maintenant, il suffit de télécharger un "gros pot" de l'ATLAS et bibliothèques JNI pour Windows, Linux, Mac OS X, 32 et 64 bits (sauf pour Windows). De cette façon, vous obtiendrez des performances natives juste en ajoutant le fichier jar au classpath. Consultez-le à l' http://jblas.org!

-M

Answer 4

J'ai juste comparé Apache Commons Mathématiques avec jlapack.

Test: décomposition en valeurs singulières d'un hasard de 1024x1024 de la matrice.

Machine: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66 GHz, linux x64

Octave code: A=rand(1024); tic;[U,S,V]=svd(A);table des matières

les résultats de temps d'exécution
---------------------------------------------------------
Octave 36.34 sec

JDK 1.7u2 64bit
 jlapack dgesvd 37.78 sec
 apache commons mathématiques SVD 42.24 sec


JDK 1.6u30 64bit
 jlapack dgesvd 48.68 sec
 apache commons mathématiques SVD 50.59 sec

Natif de routines
Lapack* invoqué à partir de C: 37.64 sec
Intel MKL 6.89 sec(!)

Ma conclusion est que jlapack appelé à partir de JDK 1.7 est très proche du natif binaire de la performance de lapack. J'ai utilisé le lapack binaire de la bibliothèque sont à venir avec des distro linux et a invoqué le dgesvd de routine afin d'obtenir le U,S et VT matrices. Tous les tests ont été fait à l'aide de double précision sur exactement la même matrice à chaque exécution (à l'exception d'Octave).

Avertissement - je ne suis pas un expert en algèbre linéaire, qui ne sont pas affiliés à l'une des bibliothèques ci-dessus et ce n'est pas une rigoureuse de référence. C'est un "fait-maison" de test, comme j'étais intéressé de comparer l'augmentation de la performance de JDK 1.7 1.6 ainsi que les communes de mathématiques SVD à jlapack.

Answer 5

Il y a un benchmark des différents de la matrice des packages en java disponible sur http://code.google.com/p/java-matrix-benchmark/ pour quelques configurations matérielles différentes. Mais c'est pas un substitut pour faire votre propre référence.

Le rendement varie avec le type de matériel que vous avez (cpu, des carottes, de la mémoire, L1-3 cache, la vitesse du bus), la taille des matrices, et les algorithmes que vous souhaitez utiliser. Les différentes bibliothèques ont différents points de vue sur la simultanéité pour les différents algorithmes, donc il n'y a pas de réponse unique. Vous pouvez également trouver que les frais généraux de la traduction de la forme attendue par une bibliothèque native nie l'avantage de performance pour votre cas d'utilisation (certains des bibliothèques java ont des options plus flexibles quant à la matrice de stockage, qui peut être utilisé pour la poursuite de l'optimisation des performances).

En général, cependant, JAMA, Jampack et le POULAIN se fait vieux, et ne représentent pas l'état de la performance actuelle en Java disponible pour l'algèbre linéaire. Plus moderne de bibliothèques de rendre plus efficace l'utilisation de plusieurs cœurs cpu et les caches. JAMA est une implémentation de référence, et à peu près implémente manuel algorithmes avec peu d'égard à la performance. COLT et IBM Ninja ont été les premières bibliothèques java pour montrer que la performance a été possible en java, même si ils ont été à la traîne de 50% derrière bibliothèques natives.