tu devrais regarder les benchs de COLT http://hoschek.home.cern.ch/hoschek/colt/(...) ), une bibliothèque de calcul numérique dont la partie calcul matriciel est en gros trois fois moins rapide que la bibliothèque MKL d'Intel
Ben désolé, mais 2,5 fois plus lent, c'est trés merdique.
<analogies_rapides_approximatives>
ça veut dire que s'il faut un PIII@500 pour décompresser une vidéo de type mpeg4, il te faudra un PIII@1250 pour faire le même boulot, et tout ça pour un code optimisé java, c'est pas du code générique java, comme l'assembleur est optimisé pour le x86.
Au lieu de mettre 1 jour pour calculer ton anim de ray-tracing ou faire ta simulation métoé, il t'en faudra 2,5, et 2,5 fois plus de temps de production c'est trop important pour être ignoré.
</analogies_rapides_approximatives>
Normalement, tu dois pouvoir atteindre 90% des perfs globales d'un programme optimisé à la mimimine en assembleur, avec un langage compilé.
Surtout sur du code itératif en boucle comme le calcul matriciel.
En plus, sur ce genre de code un compilateur JIT doit à priori si il est bien fait être plus rapide qu'un programme compilé statiquement, car le JIT améliore l'optimisation à chaque itération.
HP avait fait des essais avec un compilateur JIT PA 8000 "dynamo"sur leur proc pa 8000, dans les calculs intensifs, le programme gagnait 20% de perf sur le JIT qu'executé nativement.
[^] # perf compilos java
Posté par darkleon . En réponse à la dépêche Microsoft brevette les API de .NET. Évalué à 1.
Ben désolé, mais 2,5 fois plus lent, c'est trés merdique.
<analogies_rapides_approximatives>
ça veut dire que s'il faut un PIII@500 pour décompresser une vidéo de type mpeg4, il te faudra un PIII@1250 pour faire le même boulot, et tout ça pour un code optimisé java, c'est pas du code générique java, comme l'assembleur est optimisé pour le x86.
Au lieu de mettre 1 jour pour calculer ton anim de ray-tracing ou faire ta simulation métoé, il t'en faudra 2,5, et 2,5 fois plus de temps de production c'est trop important pour être ignoré.
</analogies_rapides_approximatives>
Normalement, tu dois pouvoir atteindre 90% des perfs globales d'un programme optimisé à la mimimine en assembleur, avec un langage compilé.
Surtout sur du code itératif en boucle comme le calcul matriciel.
En plus, sur ce genre de code un compilateur JIT doit à priori si il est bien fait être plus rapide qu'un programme compilé statiquement, car le JIT améliore l'optimisation à chaque itération.
HP avait fait des essais avec un compilateur JIT PA 8000 "dynamo"sur leur proc pa 8000, dans les calculs intensifs, le programme gagnait 20% de perf sur le JIT qu'executé nativement.
http://www.arstechnica.com/reviews/1q00/dynamo/dynamo-3.html(...)