Discussion :

[3DArchi]

C++ vainqueur d'un benchmark avec Java, Scala et Go
Présentée aux Scala Days, l'étude portait sur l'implémentation d'un algorithme

Bonne nouvelle pour tous les amateurs de C++ ! Ce langage reste le plus performant et sans conteste !

Présenté au Scala Days en début de mois, un benchmark met en compétition le C++, Java, Scala et GO pour l'implémentation du même algorithme en cherchant à s'appuyer sur les éléments du langage (pas de Boost ici donc). Et C++ remporte haut la main en temps d'exécution mais aussi en empreinte mémoire. Mieux, contrairement à certaines idées reçues, les temps de compilation ou le nombre de ligne de code restent à des valeurs qui n'ont pas à rougir face à Java par exemple. Ceci souligne l'expressivité du langage et la qualité des compilateurs.

Retrouvez l'annonce aux Scala Days 2011

Téléchargez le document d'analyse des résultats : Loop Recognition in C++/Java/Go/Scala, Robert Hundt

Téléchargez et améliorez () les codes sources : multi-language-bench

[Voyvode]

Après consultation rapide du document, les résultats ne sont guère étonnants.

En revanche, il manque un détail important dans ce sujet qui a été précisé dans les conclusions :

We find that in regards to performance, C++ wins out by a large margin. However, it also required the most extensive tuning efforts, many of which were done at a level of sophisti- cation that would not be available to the average programmer.

Comme d'habitude, le C++ est très performant, mais sa puissance se mérite.

D'un autre côté, Java est le langage où ils ont éprouvé le moins de difficulté pour coder l'algorithme. On voit toutefois qu'il a un véritable problème avec la mémoire et que son garbage collector est difficilement optimisable.

Edit : Apparemment, cela est du à un problème d'implémentation inefficace de l'algorithme en Java.

[Klaim]

Oui en fait rien de nouveau et il serait bien que la partie sur le fait que C++ reste le plus difficile à maitriser pour extraire un max de perfs soit aussi mis en valeur.

Comme ça ça équilibre les annonces au lieu de leur faire ressembler a des trolls.
Au passage, a priori c'est juste une confirmation plus ou moins objective d'un constat qu'on n'arrive a faire que par l'observation sur le long terme.

[nonpoluant]

Cette annonce avait déjà été faite et mieux commenté : http://www.developpez.net/forums/d10...-performances/

[Franck SORIANO]

En revanche, il manque un détail important dans ce sujet qui a été précisé dans les conclusions :

We find that in regards to performance, C++ wins out by a large margin. However, it also required the most extensive tuning efforts, many of which were done at a level of sophisti- cation that would not be available to the average programmer.

Comme d'habitude, le C++ est très performant, mais sa puissance se mérite.

Je trouve surtout que la formulation de la conclusion est mensongère voir erronée (sans parler du fait que l'auteur se contredit en disant : The Java version was [...] the hardest to analyze for performance).
Il faut comparer des choses qui sont comparables. Si on veut comparer "l'effort d'optimisation", il faut le comparer pour obtenir le même résultat.
Dire qu'il a fallu faire plus d'efforts pour arriver à un code 12,6 fois plus rapide que Java... ça ne rime pas à grand chose. Dailleurs, si on regarde les gains qu'ils ont obtenus avec l'ensemble des optimisations C++, toutes réunies, j'ai bien l'impression que la version C++ non optimisée était déjà plus rapide que le code qu'ils n'ont plus réussi à "optimisé" en Java.
C'est dommage également, pour Java ils sont aller comparer Java 32 bits et Java 64 Bits, mais quelqu'un peut me dire s'ils ont utilisé un compilo C++ en 32 Bits ou 64 Bits ?

Lorsqu'on dit que les optimisations réalisées n'étaient pas à la porté du développeur moyen. Si on veut faire une vrai comparaison avec les autres langages, on devrait aussi dire que dans les autres langages, elles ont été impossible même pour les meilleurs experts.

Aussi je serais plutôt d'avis de dire :
"C++ a permis d'aller beaucoup plus loin dans l'optimisation et d'effectuer notamment des optimisations qui ne sont pas à la porté du premier venu, voir qui étaient tout simplement impossible à faire dans les autres langages."

Maintenant globalement, la conclusion que je retiens personnellement de ce "bench" c'est :
- Avec Go, le compilateur est immature et le code généré n'est pas performant.
- Avec Java et Scala : Les performances sont limitées par le GC. Les "experts" de Google n'ont pas pu résoudre le problème ni le contourner.
- Avec C++ les limitations rencontrées sont avant tout celles des compétences du développeur.

En parlant des performances, je vois souvent sur Dvp :
"Les mauvais développeurs feront du mauvais code quel que soit les outils (le langage) qu'on leur donne".
Mais on passe sous silence que les meilleurs experts ne peuvent pas faire mieux que ce que leurs outils permettent.

[Voyvode]

Il faut comparer des choses qui sont comparables. Si on veut comparer "l'effort d'optimisation", il faut le comparer pour obtenir le même résultat.
Dire qu'il a fallu faire plus d'efforts pour arriver à un code 12,6 fois plus rapide que Java... ça ne rime pas à grand chose.

Tout dépend de l'objectif du développement. L'aspect performance est critique pour certains programmes et beaucoup moins prioritaire pour d'autres.

Lorsqu'on dit que les optimisations réalisées n'étaient pas à la porté du développeur moyen. Si on veut faire une vrai comparaison avec les autres langages, on devrait aussi dire que dans les autres langages, elles ont été impossible même pour les meilleurs experts.

J'ai découvert sur le blog de Jeremy Manson – qui a travaillé sur son optimisation – que l'algorithme en Java est handicapé par une flopée d'instanciations inutiles et une utilisation inefficace des collections. L'occupation mémoire excessive peut d'ailleurs s'expliquer par cela.
Il semblerait que Robert Hundt soit très bon avec C++ mais beaucoup moins à l'aise avec Java.

En parlant des performances, je vois souvent sur Dvp :
"Les mauvais développeurs feront du mauvais code quel que soit les outils (le langage) qu'on leur donne".
Mais on passe sous silence que les meilleurs experts ne peuvent pas faire mieux que ce que leurs outils permettent.

Ne t'en déplaise, cette phrase qui circule tellement sur Développez semble se vérifier une fois de plus.

[Franck SORIANO]

Tout dépend de l'objectif du développement. L'aspect performance est critique pour certains programmes et beaucoup moins prioritaire pour d'autres.

Bien sûr. Mais ce n'est pas une raison pour dire n'importe quoi lorsqu'on prétend comparer les performances des différents langages.
Encore qu'en pratique, lorsqu'on croit que les performances ne sont pas critiques, en réalité bien souvent on est sur une appli serveur et la consommation de ressources (en particulier CPU) est critique.
Mais les développeurs ne s'en rendent compte qu'une fois l'appli mise en prod, lorsque le serveur ne tient pas la charge... ou qu'il faut 10 serveur pour absorber une charge qui pourait tenir sur un seul.

Ne t'en déplaise, cette phrase qui circule tellement sur Développez semble se vérifier une fois de plus.

Mais je suis tout à fait d'accord avec cette affirmation
Le problème c'est que dans le contexte où elle est généralement utilisée, on veut faire croire que parce qu'un mauvais développeur fait du mauvais travail, tous les langages se valent entre les mains de développeurs compétents.
Comme tu viens de le dire, on a ici une belle illustration de la réalité des choses...

Le bon développeur doit avant tout savoir choisir l'outil approprié pour le résultat recherché.

[Gouyon]

Le bon développeur doit avant tout savoir choisir l'outil approprié pour le résultat recherché.

Je ne dirais pas mieux (vu que c'est ma politique). Au vu de ma modeste expérience je reste persuadé qu'il n'existe aucun langage idéal ni (OS d'ailleurs) et que tout comme le mécanicien, il faut employer l’outil le mieux adapté au résultat qu'on veut obtenir. Si ce genre de test est intéressant car il titille la curiosité naturelle du développeur, d'un point de vue pratique il ne permet pas de conclure à la supériorité d'un langage sur un autre. La supériorité restant d'ailleurs difficile à définir un peu comme l'intelligence.

[revlis]

Java serait le language "où ils ont éprouvé le moins de difficulté pour coder l'algorithme"...
Mais comme au final, certains remettent en cause l’implémentation de l'algorithme et trouve deux ou trois truc a optimiser, on en déduit qu'il n'est pas si "simple" que cela, et qu'un certain niveau de compétence est nécessaire pour l'optimiser correctement...

[développeur2013]

We find that in regards to performance, C++ wins out by a large margin. However, it also required the most extensive tuning efforts

sans parler du fait que l'auteur se contredit en disant : The Java version was [...] the hardest to analyze for performance).

Je pense que l'auteur veut dire que plus de temps a été passé pour optimiser C++ mais que le niveau d'analyse nécessaire pour les optimisations JAVA était plus élevé (car il faut réfléchir sur le fonctionnement du gc et pas uniquement sur l'efficacité des instructions elles-mêmes)

[développeur2013]

C'est intéressant mais il semble que la version JAVA pourrait être encore améliorée.
Par exemple il est dit dans le rapport que de nombreuses améliorations appliquées au code C++ pourraient aussi s'appliquer au JAVA:

Note that Jeremy deliberately refused
to optimize the code further, many of the C++ optimizations
would apply to the Java version as well.

De plus il est clairement dit que plus d'efforts ont été déployés pour optimiser C++. Pourquoi ne pas avoir passé plus de temps sur JAVA si certaines améliorations étaient déjà identifiées?

C'est dommage du coup ça laisse le doute!
Je pense qu'il faut attendre un peu, il y a bien un fervent défenseur de JAVA qui va tenter de sauver l'honneur de ce langage en améliorant le code

[Franck SORIANO]

En même temps, quand on lit l'introduction :

The implementations each use the languages’ idiomatic container classes, looping constructs, and memory/object allocation schemes. It does not attempt to exploit specific language and run-time features to achieve maximum performance.

Comparer les performances obtenues après ça... c'est plutôt osé...

[Klaim]

En même temps ils disent aussi que l'idée au départ c'était de voir les perfs quand on utilise les features de base du language, sans aller dans les optimizations.

Autrement dit, les performances "par défaut". L'elasticité des performance c'est autre chose...

[Franck SORIANO]

Oui mais il faut savoir ce qu'on veut.
Soit on fait une comparaison brut de fonderie : Qu'est-ce qu'on obtient avec un premier jet, sans faire d'effort d'optimisation.
Soit on optimise et on utilise tous les moyens à notre disposition.

Mais on ne prétend pas comparer des performances sur des codes à moitié optimisés. Et encore moins : "an almost fair comparison".