Discussion :

[Davidbrcz]

Une étude compare différents langages pour le calcul intensif
Le résultat va-t-il vous faire changer de langage ?

Une équipe universitaire a sorti une étude comparant différents langages pour le calcul intensif. L'étude se base sur un modèle économique mais peut être appliqué à d'autres domaines.

Ils ont comparé

• C++11
• Fortran 2008
• Java
• Julia
• Python
• MATLAB
• Mathematica
• R

Afin de na pas biaiser les résultats, ils n'ont en général pas cherché à tirer profit des particularités de chaque langage. L'étude ne commente pas la difficulté à porter l'algorithme dans un langage donné.

Les résultats principaux sont :

• Le C++ et Fortran tiennent toujours les meilleures performances
• L'avantage du C++ sur le Fortran n'est que de 5-7%
• Julia avec son compilateur JIT donne un exécutable qui tourne en moyenne 2.7 fois plus lentement que le meilleur programme C++
• L’implémentation Pypy donne un programme 44 fois plus lent que celui en C++. Quant a l’Interpréteur CPython, la facteur oscille entre 155 et 269
• Utiliser Numba (un compilateur JIT Python) , demande de revoir un peu le code mais donne des performances très proches du C++ (1.6 plus lent en moyenne)
• MATLAB est entre 9 et 11 fois plus lent que le C++. Mais combiné avec des fichiers Mex, la différence tombe entre 1.24 et 1.64
• R est entre 500 et 700 fois plus lent que le C++. Compiler le code augmente par deux la performance
• Mathematica donne de bonnes performances (4 fois lent que le C++) mais au prix d'un grand effort de ré-écriture de code pour tirer parti des optimisations du langage,

Les résultats détaillés sont ici et le code est accessible sur Github

Cette étude va-t-elle vous faire changer de langage pour vos applications lourdes en calcul ?

[Shuty]

...

• Le C++ et Fortran tiennent toujours les meilleures performances
• L'avantage du C++ sur le Fortran n'est que de 5-7%
• Julia avec son compilateur JIT donne un exécutable qui tourne en moyenne 2.7 fois plus lentement que le meilleur programme C++
• L’implémentation Pypy donne un programme 44 fois plus lent que celui en C++. Quant a l’Interpréteur CPython, la facteur oscille entre 155 et 269
• Utiliser Numba (un compilateur JIT Python) , demande de revoir un peu le code mais donne des performances très proches du C++ (1.6 plus lent en moyenne)
• MATLAB est entre 9 et 11 fois plus lent que le C++. Mais combiné avec des fichiers Mex, la différence tombe entre 1.24 et 1.64
• R est entre 500 et 700 fois plus lent que le C++. Compiler le code augmente par deux la performance
• Mathematica donne de bonnes performances (4 fois lent que le C++) mais au prix d'un grand effort de ré-écriture de code pour tirer parti des optimisations du langage,

Et le java du coup... ?

[Grabeuh]

Et le java du coup... ?

Il mouline toujours...

[Adrass]

Il faut allez voir les résultats complets....
java 2.69 fois plus lent 3 ème.

[NicoV]

Il mouline toujours...

la méthode de comparaison est assez mal faite :

• Les calculs ne sont faits qu'une fois par exécution, alors que parmi les langages testés certains sont compilés à la volée (Java, langages de script, ...). N'exécuter le test qu'une fois fait que le temps de compilation est compté dans le temps de calcul...
• Les options d'exécution ne sont pas étudiées (par exemple -server pour du Java est quand même la moindre des choses pour du calcul intensif).

Résultat: sur mon PC (pas une bête de course), avec ces simples points, le temps de calcul Java passe de 2.5s à 1.9s...

Avec ce genre de conditions d'analyse, les résultats ne veulent pas dire grand chose

[Aiekick]

Il mouline toujours...

Que'st ce que j'ai rit merci.

M'enfin ont peut dire ce qu'on veut, pour le C++ et le fortran, on discute jamais tout le monde est d'accord, et comme par hazard, le java on critique toujours plein de trucs donc la methode..
c'est bien la preuve que le java est une horreur sur patte

[tomlev]

Afin de na pas biaiser les résultats, ils n'ont en général pas cherché à tirer profit des particularités de chaque langage.

Bah c'est complètement débile

Quand on utilise un langage particulier pour une tâche donnée, c'est généralement parce qu'il y est particulièrement adapté. Je me fous pas mal de savoir si X est plus rapide que Y sans utiliser les particularités de Y ; si justement ces particularités permettent à Y d'être plus rapide pour la tâche que je dois effectuer, c'est Y que je choisirai, parce qu'il est plus adapté.

Un langage n'est pas "meilleur" ou "plus performant" qu'un autre dans l'absolu, il faut utiliser le plus approprié à chaque besoin et c'est tout...

[polaroid62]

Surtout si tu peux optimiser ça via le compilateur , autrement ça n'a pas de sens .

[nchal]

Il y a un concours organisé pour savoir qui va arriver à pondre l'étude la plus débile ? Parce qu'en ce moment, on est bien servi.

Si on me dit, "on va comparer les performances en cherchant à optimiser le code le plus possible suivant le langage", je dis OUI, un grand OUI. On sait tous que le C++ est le plus rapide, mais on ne sait pas si le Java est 15x ou 2x plus lent, et ça peut-être intéressant comme info. Mais l'étude se présente comme un bête copier-coller entre les langages, alors qu'il aurait pu sortir quelques préco sur comment programmer ou configurer la JVM par exemple pour optimiser les perfs Java.

[Gugelhupf]

Tu peux augmenter la mémoire pour Java mais je ne vois pas trop ce qui pourrait changer, sachant que pour faire leur bench ils utilisent un petit tableau.
Je le trouve un peu moyen leur bench, il y a mieux ici (avec plus de langages, et pas de copier/coller d'algorithme entre les langages).

[Sekigo]

Si on me dit, "on va comparer les performances en cherchant à optimiser le code le plus possible suivant le langage", je dis OUI, un grand OUI. On sait tous que le C++ est le plus rapide, mais on ne sait pas si le Java est 15x ou 2x plus lent, et ça peut-être intéressant comme info. Mais l'étude se présente comme un bête copier-coller entre les langages, alors qu'il aurait pu sortir quelques préco sur comment programmer ou configurer la JVM par exemple pour optimiser les perfs Java.

L'exemple en python est assez éloquent.
Le code de base, un script impératif de base, sans fonction, est ~200x plus lent que le code en C. En factorisant un poil (on déplace 10 lignes de code de la boucle principale pour les mettre dans une fonction, on déclare la fonction et on ajoute un décorateur), on arrive à un facteur 1.57x plus lent que le code en C. C'est complètement absurde.
En utilisant un poil les fonctionnalités/écosystème du langage, on arrive à des résultats qui n'ont plus rien à voir.

[Invité]

L'exemple en python est assez éloquent.
Le code de base, un script impératif de base, sans fonction, est ~200x plus lent que le code en C. En factorisant un poil (on déplace 10 lignes de code de la boucle principale pour les mettre dans une fonction, on déclare la fonction et on ajoute un décorateur), on arrive à un facteur 1.57x plus lent que le code en C. C'est complètement absurde.
En utilisant un poil les fonctionnalités/écosystème du langage, on arrive à des résultats qui n'ont plus rien à voir.

Croyez-moi c'est réaliste, j'ai travaillé avec un économètre qui codait en python , ce genre "d’optimisation" il n'y aurait JAMAIS pensé

[Aiekick]

Bah c'est complètement débile

Quand on utilise un langage particulier pour une tâche donnée, c'est généralement parce qu'il y est particulièrement adapté. Je me fous pas mal de savoir si X est plus rapide que Y sans utiliser les particularités de Y ; si justement ces particularités permettent à Y d'être plus rapide pour la tâche que je dois effectuer, c'est Y que je choisirai, parce qu'il est plus adapté.

Un langage n'est pas "meilleur" ou "plus performant" qu'un autre dans l'absolu, il faut utiliser le plus approprié à chaque besoin et c'est tout...

enfin la c'est meme pas le langage en lui meme qui est dritiqué, c'est plutot les compilateurs/interpreteur voir la methode d'execution, parce que a ce compte la en assembleur ca va etre galere de faire des op matricielle mais on peut y arriver ( quand tu voit ce qu'arrive a faire les gars des demo 4k en full asm ), apres tout au final le seul langage executé par le proc c'est l'assembleur

[Aiekick]

Moi ce qui m'a fait choisir le C++, c'est les possibilités offettes pas le langage, on peut quasiment tout faire, voir integrer du code asm. Quitte à y passer des années si on doit en maitriser un autant que s'en soit un qui puisse tout faire ou presque. mais qui soit quand meme plutot accessible. (l'assembleur est pas vraiment accessible a mon sens ou sur certain fonction, comme les fonction matricielle de base )
Java ou C# on est bloqué, déja rien que de penser qu'il y a un ramasse miette en tache de fond et qui se declenche quand bon lui semble sans qu'on puisse y faire grand chose, ca me fou la migraine...
Si je veux un ramasse miette je peux me le faire en c++, mais quel interet, les pointeurs c'est tellement bien que franchement en avoir peur est absurde. oui c'est sur faut savoir ce qu'on fait c'est tout.

[Saverok]

Un langage de haut niveau est justement fait pour abstraire la technique non liée à ton algorithme. (ainsi, le développeur peut se concentrer sur les fonctionnalité de son programme et non sur la technicité de son matériel qui le détourne de la raison même pour laquelle il développe)
Après, je ne dis pas qu'il faut faire n'importe quoi ou que le garbage collector de Java est bien fait, mais là est l'idée.

Un développeur ne programme pas pour la beauté du geste (ça n'a aucun sens).
Un développeur programme des fonctionnalités.
Toute l'intention du développeur se doit d'être concentrée là dessus et les considérations techniques le détournent de cet objectif.
C'est la raison pour laquelle de plus en plus d'API permettent de faire de la génération de code par des annotations.

OK, côté perf, le C++ est meilleurs que Java, pas trop de débat là dessus.
Côté accessibilité, rapidité de développement, lisibilité du code, maintenance et portabilité : Java passe devant

[Aiekick]

Un langage de haut niveau est justement fait pour abstraire la technique non liée à ton algorithme. (ainsi, le développeur peut se concentrer sur les fonctionnalité de son programme et non sur la technicité de son matériel qui le détourne de la raison même pour laquelle il développe)
Après, je ne dis pas qu'il faut faire n'importe quoi ou que le garbage collector de Java est bien fait, mais là est l'idée.

Un développeur ne programme pas pour la beauté du geste (ça n'a aucun sens).
Un développeur programme des fonctionnalités.
Toute l'intention du développeur se doit d'être concentrée là dessus et les considérations techniques le détournent de cet objectif.
C'est la raison pour laquelle de plus en plus d'API permettent de faire de la génération de code par des annotations.

OK, côté perf, le C++ est meilleurs que Java, pas trop de débat là dessus.
Côté accessibilité, rapidité de développement, lisibilité du code, maintenance et portabilité : Java passe devant

je suis d'accord avec toi mais je pense qu'il est illusoire de penser que peut importe comment l'on code, le compilateur ou l'interpetreuir soit capable de faire le meilleur code, le moin consommatteur de cycle et de memoire vive.

Moi je code avant tout pour la perf et j'implemente fonction de ce que le langage me permet et l'utilisation des pointeurs reduit de beaucoup la complexite des implementation sans comtper la rapidité en c++.
C'est sur que l'implementation sera specifique et pas forcement convertible facilement au java ou au c# ou tout est objet, mais je vais pas laisser a un process automatique, dont je ne controle pas le processus, les optimisations que je peux faire moi meme.

Si on code extremement reutilisable on peut vouloir utiliser des regles d'implementation basique aisement comprehensible par n'importe qui et laisser de toute facon comme c'est à la mode la sur-puissance des becanes gérer le code non optimisé comme si c'était du code opti sur un 386. par contre si on code du code rapide avec une faible emprunte memoire, alors bien connaitre le langage et la facon dont le compilateur va traiter telle protion de code est obligatoire et forcement moins à la portée, mais au fond, vous c'est quand meme bien que l'implementation soit aussi soignement faite que la conception de l'algo.

et qui dit langage de haut niveau dans ton example dit langage livré avec framework. et la pardon, charger en memoire le framework alors qu'on a besoin de 4 fonctions c'est une abbération à mon sens. j'aime coder ce que je comprends. et la couche d'abstraction fournie par les framework me pose probleme.

Non seulment je comprends pas comment il focntionne en interne et au 1er bug venu toute mon implementation tombe en morceau.
je dis pas qu'il faut tout reccrire, mais a force de ce reposer sur tout un tas de truc ecrit par d'autre sur le seul avantage qu'on n'as quasiment plus qu'a convetir l'algo textuellement est trop cher payé. enfin totu depend de la criticté de l'algo en question pour la focntionnalité voulu.

[guillaume07]

c++

[cueffic]

Dommage, il n'y a pas de test sur Linux.
en sachant que pratiquement tous les super calculateurs sont sur Linux

[spidetra]

Dommage, il n'y a pas de test sur Linux.
en sachant que pratiquement tous les super calculateurs sont sur Linux

Dommage surtout qu'il n'y a pas de tests de calculs intensifs
Le test est basé sur un vecteur de 17.000 entrées. C'est à dire peanuts !
En ce moment traiter une matrice de 500.000 entrées, ça me prend juste quelques secondes en java sur une vieille rogne (un amd athlon) et sans aucune recherche d'optimisation.

[pvincent]

Pour que la discussion ne tourne pas en rond, reste à définir ce qu'on entend par "calcul intensif" (calcul linéaire, bases de données,...) et à quel type de machine on s'intéresse.

Pour les "supercomputers", il n'y a pas photo: la référence c'est le Top500 (http://www.top500.org/project/introduction/) basé sur LINPACK et bien évidemment orienté vers le calcul linéaire.

[troll] Avec la mentalité actuelle, rien ne m'empêche de qualifier de calcul intensif un run de 48 heures sur mon PC personnel, ce qui ne correspond évidemment pas à l'ordre de grandeur des performances que nécessite les prévisions météorologiques de la Météo Nationale.[/troll]