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é.

[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...

[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.

[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".

[JCB001]

dire "Ce langage reste le plus performant et sans conteste !" est à mon sens, à relativiser : le plus performant dans quel domaine ?
Si on veut le langage le plus performant, le plus rapide, avec l'exe le plus léger c'est l'assembleur, qu'on aime ou que l'on aime pas :-;
Sinon pour ceux qui ne veulent pas d'assembleur on a le C, un peu plus performant que le C++ (très faibles différences).
Après si on compare par rapport à la vitesse d'écriture et au plus faible nombre de bugs, à la sécurité du code, je pense que java est plus performant que C++...

De plus Java est surtout utilisé avec des serveurs JSP, où souvent le facteur limitant est la base de données et non le langage y accédant... donc c'est un faux problème.

[JolyLoic]

Sinon pour ceux qui ne veulent pas d'assembleur on a le C, un peu plus performant que le C++ (très faibles différences).

Sans donner mon avis sur le reste du message, je suis en désaccord avec ce point en particulier :

A niveau d'abstraction égal, le C++ est plus performant que le C, car il fournit de meilleurs outils d'abstraction (exemple classique : qsort vs std::sort).
En outre, il est toujours possible d'utiliser le C++ au même niveau d'abstraction que l'on aurait utilisé le C (en première approximation, un code C est compilable en C++, et pour les points de blocage, les corrections à apporter sont sans coût au runtime).

Je ne vois donc vraiment pas en quoi le C pourrait être plus performant que le C++.

[Franck SORIANO]

Après si on compare par rapport à la vitesse d'écriture et au plus faible nombre de bugs, à la sécurité du code, je pense que java est plus performant que C++...

Lorsqu'on parle des performances d'un langage, il s'agit d'un terme très précis qui désigne l'efficacité du code obtenu. Ou si tu préfères, la vitesse d'exécution.

De plus Java est surtout utilisé avec des serveurs JSP, où souvent le facteur limitant est la base de données et non le langage y accédant... donc c'est un faux problème.

Est-ce que tu as déjà réalisé un test de monté en charge d'un serveur Web ?
Il s'agit là d'une idée reçue complètement fausse.

Lorsque tu fais ton test de monté en charge, ce qui lache en premier en générale c'est la consommation CPU du serveur Web, et selon la façon dont l'appli est écrite, la consommation mémoire n'est pas très loin.
On peut améliorer la monté en charge en ajoutant d'autres serveurs Web en load-balancing. En revanche, une base de données ne se load-balance pas !
Si la base de données était le facteur limitant, il serait inutile d'ajouter des serveurs Web puisque la base serait déjà saturée avec un seul !

La base de données comme facteur limitant, c'est ce que pense les développeurs lorsqu'ils développent un traitement unitaire dans leur coin :
Un seul client qui solicite le système, on lance le traitement, et on regarde le temps de réponse unitaire, et on se rend compte qu'on passe le plus de temps dans l'exécution des requêtes faites sur la base.
Sauf qu'on utilise des caches pour ne pas avoir à refaire les mêmes requêtes sur la base.
De plus en générale, les requêtes sont triviales, la base de données met à peine quelques microsecondes pour calculer la requête. Et l'essentiel du temps de traitement se passe dans l'API d'accès à la base de données, sur le poste client ! Donc de la consommation CPU côté serveur Web (la trame réseau est décodée une première fois par le pilote natif du SGBD, puis elle est transformée, convertie, convertie encore... en remontant les 50 couches d'encapsulation des différentes API... est convertie encore dans les DAO de l'appli, voir par un ORM...).
Et lorsque ce n'est pas l'API cliente qui travaille, ce sont des temps d'attente liés pour l'essentiel à la latence du réseau.

Sur un serveur digne de ce nom, il n'y a pas qu'un seul client. Le serveur est multi-threadé, de sorte que les temps d'attentes précédents sont récupérés pour traiter un autre client pendant ce temps.
Globalement, lorsque la charge du serveur augmente (le nombre de clients simultanés augmente), les temps de réponses se dégradent lentement parce qu'il faut trouver des "trous" à récupérer pour servir tous les clients. La dégradation des performances est proportionnelle à la probabilité d'avoir une collision pour l'utilisation d'une ressource critique (le plus souvent, le CPU).
Jusqu'à ce qu'il n'y ait plus de trou à récupérer : On a atteind le point de saturation du serveur, et les temps de réponse s'écroulent d'un coup.

Si ton langage de développement est un gouffre à CPU (ou à mémoire), tu atteindras le point de saturation du serveur Web bien plus tôt...

D'ailleurs, lorsque Facebook à fait HipHop pour convertir leur site PHP en C++, ils ont bien démontré l'importance des performances du langage.

[Klaim]

Et il me semble que l'auteur de CPPCMS avait aussi fait un benchmark pour confirmer ce que tu expliques aussi.

[white_tentacle]

D'ailleurs, lorsque Facebook à fait HipHop pour convertir leur site PHP en C++, ils ont bien démontré l'importance des performances du langage.

Oui enfin là tu parles de php, le langage on l’on passe un temps fou à relire tout le temps le même code et le recompiler JIT. Il y a un facteur de perf de 10 entre php et c++ sur des gros projets.

Pour le reste, je suis d’accord avec ton analyse que je partage totalement.

[Franck SORIANO]

Oui enfin là tu parles de php, le langage on l’on passe un temps fou à relire tout le temps le même code et le recompiler JIT. Il y a un facteur de perf de 10 entre php et c++ sur des gros projets.

J'aurai dit un coefficient encore supérieur
C'est sur les extrêmes qu'on comprend ce qu'il se passe à une échelle plus réduite.
Mais même avec un coef de 2, si ça permet de diviser par deux le nombre de serveur nécessaire, on divise par 2 les coûts d'exploitation. C'est loin d'être négligeable !