Discussion :

[gbdivers]

Bonjour à tous

Non, ce n'est pas un troll

Je suis tombé sur ce message du blog du concepteur du logiciel Tanagra qui a réalisé des tests pour comparer les performances à l'exécution de 2 algorithmes "classiques" (trie par bulle et produit croisé) avec plusieurs langages (C++, Delphi, C#, Java, etc.)

Les résultats mettent à mal le C++ (et surtout g++).

Comme le code est fournit, j'ai réalisé les tests pour le java et g++ sur le trie par bulle et j'ai obtenu des résultats similaires (ubuntu 10.10 64b g++ 4.5)

Vous en pensez quoi ? L'implémentation des versions C++ est à revoir (je n'ai pas regardé le code en profondeur mais ça ressemble beaucoup à du C) ? Il manque des paramètres d'optimisation ? Il faut abandonner g++ ? Le test est trop limité ? Dans ce cas, quels sont les "domaines" d'application du C++

Merci de vos commentaires

EDIT : comme d'habitude, le problème est localisé (en partie) entre l'ordinateur et la chaise... j'arrête de compiler en mode debug et les performances sont moins catastrophiques : java = 2,74 s ; C++ = 3,47 s. En utilisant des vecteurs à la place des tableaux dynamique, je passe à 3,95 s (bof) puis à 3,26 s en utilisant les itérateurs (mieux)

[Aleph69]

Bonjour,

je t'invite à relire le document. L'auteur cherche simplement à montrer que les performances d'un code dépendent en premier lieu de la capacité de son développeur à optimiser ses programmes. Il existera des différences entre couples (langage, compilation) mais elles sont moins significatives si on sait en tirer parti pour faire du code rapide.

[Emmanuel Deloget]

Non, ce n'est pas un troll

Le gout, la couleur, tout ça quand même

Mais je sais que ce n'est pas un troll.

Je suis tombé sur ce message du blog du concepteur du logiciel Tanagra qui a réalisé des tests pour comparer les performances à l'exécution de 2 algorithmes "classiques" (trie par bulle et produit croisé) avec plusieurs langages (C++, Delphi, C#, Java, etc.)

Les résultats mettent à mal le C++ (et surtout g++).

Comme le code est fournit, j'ai réalisé les tests pour le java et g++ sur le trie par bulle et j'ai obtenu des résultats similaires (ubuntu 10.10 64b g++ 4.5)

Vous en pensez quoi ? L'implémentation des versions C++ est à revoir (je n'ai pas regardé le code en profondeur mais ça ressemble beaucoup à du C) ? Il manque des paramètres d'optimisation ? Il faut abandonner g++ ? Le test est trop limité ? Dans ce cas, quels sont les "domaines" d'application du C++

Merci de vos commentaires

Lorsqu'on ne précise ni -O<level> avec g++, le programme est par défaut compilé en -O0, c'est à dire sans optimisation. Pas très intelligent pour faire des mesures de performance. C'est le cas dans les makefiles fournis par l'auteur.

D'autre part, l'auteur a joyeusement utilisé la version de g++ livrée avec Dev C++ (donc une version 3.x, voir une version 2.95). Là, c'est un crime de stupidité : pourquoi ne pas avoir utilisé une version de cfront antédiluvienne pendant qu'il y était ?

Franchement, l'article est tout sauf d'une grande utilité. L'auteur confesse lui même qu'il n'a même pas tenté d'en apprendre davantage sur le sujet du compilateur C++ qu'il utilisait, ce qui est assez exceptionnel : "je vous ait livré quelque chose qui ne servait à rien, mais comme les chiffres sont super étranges, ben ça me suffit". Les programmes de tests utilisés sont eux aussi très étrange : "choisissons des algorithmes bien spécifiques que personne n'utilise, et voyons ce que des programmes que personne n'aurait écrit font".

La conclusion est criante : "Moralité de tout ceci, nous (programmeurs) sommes les principaux responsables de la qualité de nos applications. Pas la peine de se défausser sur le « langage » ou les outils de développement. Par nos choix de structures, par une écriture judicieuse du code, adapté au problème à résoudre, adapté à la structure utilisée, nous pouvons gagner énormément en performances. Ce n’est pas vraiment une surprise finalement. Mais il est parfois bon de le dire et de le redire. "

Et bien, ça sert à quoi d'écrire un benchmark alors ?

[gbdivers]

L'auteur cherche simplement à montrer que les performances d'un code dépendent en premier lieu de la capacité de son développeur à optimiser ses programmes. Il existera des différences entre couples (langage, compilation) mais elles sont moins significatives si on sait en tirer parti pour faire du code rapide.

Dans l'absolu, tu as raison. On sait tous (ou presque ) avec l'expérience que la qualité du code joue pour 50% des performances.
Mais là, on à 20% de différence de performance entre le java et le c++ dans le meilleur des cas. J'ai essayé d'améliorer les performances du code et je suis arrivé à une différence de 0,2 s entre le java et c++ (soit 10% de différence et ça comparé à du java non optimisé)

Autre façon de poser la question : dans ce code spécifique, que peut on améliorer pour gagner en performance ?

Encore une autre façon de poser la question : qu'est ce que je ne vois pas qui explique cette différence de performance ? Pourquoi du code tournant sur JVM est plus rapide que du code "plus proche" du CPU ?

Je pense pas qu'on puisse dire "ces algorithmes sont optimisés pour le java mais pas de problème, tous les autres algorithmes sont meilleurs en C++"

EDIT :

Lorsqu'on ne précise ni -O<level> avec g++, le programme est par défaut compilé en -O0, c'est à dire sans optimisation. Pas très intelligent pour faire des mesures de performance. C'est le cas dans les makefiles fournis par l'auteur.

J'ai évidemment fait les tests avec différentes options de compilation de g++ (au moins celle que je connais, c'est à dire très peu) et donc avec -Ox : on passe de 45 s (-O0) à 2,98 s (-O3) chez moi.

EDIT (pas bien de faire des edits) :

Et bien, ça sert à quoi d'écrire un benchmark alors ?

Ce qui me dérange (chez moi ), c'est qui si j'avais, en 2 temps 3 mouvements, optimisé le code et amélioré les performances du C++ pour exploser les temps, je serais arrivé à la même conclusion que toi : le test n'est pas très significatif. Mais là...

Autre façon de dire la chose : si le C++ est effectivement plus performant mais uniquement au prix de travail et de capacité qui n'est pas à la porté de 99% des gens... bof bof

[NoIdea]

Je viens de lire le code C++ et Java, et c'est vrai qu'ils sont identiques. Cependant, il s'agit d'un code simple où les optimisations sont simples. Il ne s'agit en aucun cas d'un cas réel. Il se peut que dans ces cas, le compilateur c++ ait plus de mal à optimiser que Java.
Je connais presque rien de Java (je sais tout de même lire un code Java mais sa s'arrête là), et je me demande si par hasard en optimisant, Java ne transformait pas tous les double en int. Auquel cas, le gain en temps est facilement expliqué.

En tout cas, la complexité de l'algorithme altère plus les performance que le langage.

Cependant, je me suis toujours demandé comment les compilateurs c++ optimisaient : une fois que c'est en assembleur ? Directe dans le code c++ ?
Sont-il capable de mettre une variable en tant que globale pour éviter sa création répétitive, ...
A quel point font-ils tout à la compilation ?

[Aleph69]

Je ne reprend pas les remarques pertinentes d'Emmanuel.
En ce qui te concerne, il vaut mieux partir des tests que tu es en train de faire plutôt que faire référence à ceux de l'auteur de Tanagra.

Autre façon de poser la question : dans ce code spécifique, que peut on améliorer pour gagner en performance ?
Encore une autre façon de poser la question : qu'est ce que je ne vois pas qui explique cette différence de performance ? Pourquoi du code tournant sur JVM est plus rapide que du code "plus proche" du CPU ?

Je n'ai pas regardé les codes mais j'imagine qu'ils utilisent des implémentations "basiques" comme des traductions directes de pseudocodes par exemple. Dans un premier temps, il faut conserver ces implémentations naïves et comparer les performances en choisissant des compilateurs reconnus, dans leur dernière version, avec les bonnes options de compilation. Ensuite, pour analyser les différences, il faut faire du profiling pour voir où tu perds/gagnes. Une fois que tu auras ces informations, on pourra commencer à interpréter les résultats et proposer des améliorations en fonction des normes de chaque langage (pour les petites astuces d'accélération) et de ta machine (pour les caches).

Dans la mesure du possible, il faut essayer de tester au moins le meilleur compilo pour chaque langage (je n'ai pas vu celui de Visual par exemple).

Les mesures de performance doivent également être faites proprement. C'est un peu déplorable qu'un statisticien (l'auteur de Tanagra) mesure des temps moyens sur seulement dix prises et sans même fournir d'écart-type. Il est plutôt spécialisé dans les arbres de décision mais quand même...

Remarque : pour être tout à fait objectif, il faudrait aussi tester différentes architectures et différents systèmes d'exploitation mais bon... Il faut également faire varier les paramètres (tailles, etc) pour voir les pics de performance et le comportement asymptotique du code.

[gbdivers]

et je me demande si par hasard en optimisant, Java ne transformait pas tous les double en int

Je n'y avais pas pensé.
J'ai modifié le code pour tester différents types : je passe de 3.2 s (double 64b) à 3.01 s (float 32b) et 3.08 s (int 32b). Je gagne 0.2 s soit environ 10% du temps.

Dans la mesure du possible, il faut essayer de tester au moins le meilleur compilo pour chaque langage (je n'ai pas vu celui de Visual par exemple).

proposer des améliorations en fonction des normes de chaque langage (pour les petites astuces d'accélération) et de ta machine (pour les caches).

Je n'ai pas encore effectué de profiling sur le code (on verra ce soir ou demain) mais as tu des idées en particulier de compilateur sous linux ou d'astuces/améliorations sur ce code ?


Mon propos n'est pas vraiment de comparer les différents langages (je n'ai pas l'intention d'en apprendre d'autres que ce que je connais actuellement) mais plutôt de comprendre ce qui se passe derrière le code compilé. L'importance de l'optimisation des algorithmes dans les performances a déjà été discuté mais ce n'est pas ce qui m'intéresse ici.
Le code java donné fait "quelque chose" qui améliore les performances (durant la compilation ? dans la JVM ?). Naïvement, je me dis que l'on peut forcement faire la même chose en C++. Donc comment obtenir ce "quelque chose" en C++ ? Et comment savoir ce qu'est ce "quelque chose" ?


De manière plus générale, si on a une "fonctionnalité" à implémenter, que l'on choisit le meilleur algorithme, que l'on optimise, que l'on teste, que l'on profile, etc. sans compter son temps de travail et son énergie, sera-t-il possible de toujours obtenir de meilleurs performances en C++ ?


Je suis d'accord avec vos remarques (c'est d’ailleurs pour ça que j'ai refait les tests et essayé d'optimiser) mais ça me perturbe quand même cette histoire

[jblecanard]

Si je copie colle le tri à bulles dans Visual Studio 2008, et que je compile en Release, le temps annoncé est de... 1,8 secondes. A comparer au 4,9 de l'article . Le code java, sur la même machine, en met 4,1.

Cependant, je me suis toujours demandé comment les compilateurs c++ optimisaient : une fois que c'est en assembleur ? Directe dans le code c++ ?

C'est assez compliqué. Le code est compilé dans plusieurs langages machines "intermédiaires" (il me semble qu'il y a une machine à pile par exemple dans g++), et des optimisations peuvent être réalisées sur chacun d'entre eux. Nous avons un certain Jean Marc Bourquet sur ce forum qui saurait nous en dire plus sur le sujet.

[gbdivers]

J'ai le souvenir de messages sur ce problème des compilateurs c++ (il existe aussi icc et intel-je-sais-plus-quoi). Je regarderai/installerai/testerai demain et je vous dirais les résultats

[Joel F]

un bon non bench bien inutile ... pour n'importequel algo et n'importequel langage, tu peux via mauvaise foi classer les dits langages dans l'ordre que tu veux.

[Arzar]

Bonjour à tous

Non, ce n'est pas un troll

Moui. ಠ_ಠ

Bon, blague à part, j'ai l'impression que l'auteur à l'origine du post s'est planté quelques part dans ses mesures en C++. Il le suspecte lui-même d'ailleurs :
"Reste le cas du compilateur G++ qui me laisse réellement perplexe. Lui aussi a bénéficié de l’amélioration, mais il demeure en dernière position, bien loin de C++ Builder à code source égal. Je pense que j’ai vraiment mal paramétré le compilateur, j’ai bien cherché pourtant. Il y a encore du travail de ce côté‐là."

En faisant un copier coller rapide des codes C++ et C# dans Visual Studio 2010 et en compilant en release () j'obtiens :

F:\Code\programming_language\TriBulles>call TriBullesCSharpRelease
Duree des calcul = 5195 ms.
Duree des calcul = 5242 ms.
Duree des calcul = 5304 ms.

F:\Code\programming_language\TriBulles>call TriBullesCppRelease.exe
duree = 2121 ms.
duree = 2122 ms.
duree = 2121 ms.

F:\Code\programming_language\CrossProd>call CrossProdCsharpRelease.exe
Temps de calcul = 8564 ms.
Temps de calcul = 8362 ms.
Temps de calcul = 8487 ms.

F:\Code\programming_language\CrossProd>call CrossProdCppRelease.exe
Temps de calcul = 4181 ms.
Temps de calcul = 4353 ms.
Temps de calcul = 4166 ms.

Sans surprise...

[LittleWhite]

Je pense qu'il est bien beau de chercher à savoir quel langage est le plus rapide (surtout que généralement cela dépend des capacités du codeur + du compilateur) (comme il a été dit, prendre une vieille version de G++, c'est un crime).
Mais, je trouve qu'il est aussi compliqué de pouvoir programmé correctement dans tout les langages (même dans celui dans lequel je me spécialise, je n'y arrive pas vraiment )
Pour moi, le Java que je connais peu, pour une implémentation basique du jeu de la Vie (Conway), j'ai eu des résultats catastrophiques (avec affichage graphique). Tout cela car je ne sais pas vraiment utiliser le langage ni les classes que celui-ci me propose.
Donc oui, surement que le problème venait de moi (je n'en doute pas) mais dans le manque de temps, je suis retourné sur un langage un peu mieux maitrisé (le C++) j'ai refait mon implémentation est hop j'ai eu des résultats cohérents.
Donc, le problème est bien réel, il faut connaitre par coeur son langage et les réactions que celui-ci a, pour pouvoir faire un truc correct (comme ont dit qu'il le pas utilisé le Vector en JAVA ...)

De plus, il faut savoir ce faire plaisir. Je ne veux pas spécialement coder en C++ mais comme c'est celui avec lequel j'ai les meilleurs résultats, je le reprends toujours.
Par contre, lorsque je cherche moins les performances, je prends un langage ou je m'amuse (JAVA / C# ou autre) (et puis cela me change du C++)

[gbdivers]

Bon, j'ai installé le compilateur Intel (icpc) pour faire des tests. Malheureusement, comme je le connais pas, je compile sans option et donc les performances ne sont pas meilleures (j'ai testé avec l'option -fast mais le compilateur tourne sans fin)

J'ai également réalisé des profiling sur les différentes versions (valgrind). A part les allocateurs des itérateurs de la stl (qui prennent à eux seuls 20%), je n'ai rien trouvé qui permettrait de gagner en performances.

Comme certaine personne ont fait la remarque, je précise : mon but n'est pas de lancer un troll (j'ai renommé la discussion pour éviter que ça parte dans ce sens). Mon interrogation est plus générale : comment optimiser au maximum le code (oui, je sais, c'est de la micro optimisation).

Pour le moment, la seule option est de changer de compilateur. Je vais approfondir cette voie demain. Pour ce qui est de l'optimisation des caches, je suppose (j'espère) que sur du code aussi simple, la plupart des compilateurs feront les optimisations (non ?) Sinon, comment on peut "jouer" avec ces paramètres ? Dans le code ou au niveau du compilateur ?

Au final, ce qui m'embête le plus, c'est que je suis juste capable d'apporter 2-3 améliorations au code (c'est déjà pas si mal, je gagne 0,5 s par rapport au code initial) mais rien de vraiment fulgurant.
Ce que j'aimerai savoir, c'est si vous deviez apporter des améliorations du code du TriBulle donné, que feriez vous ? Ou alors, ne code n'est pas améliorable et les différences viendront uniquement de la qualité du code généré par le compilateur ?
(quand je parle d'amélioration du code, je mets évidement de côté les considérations de maintenabilité ou autre, qui seront prépondérantes dans du vrai code de la "vraie vie" mais qui m'intéresse pas ici... en d'autres termes, pour les débutants qui passeraient par hasard sur ce post, ce que je fais n'est pas à faire )

Merci de vos messages (et vous inquiétez pas, j'ai bien compris le message : les benchmarks du pdf ne sont pas valides)

[Jean-Marc.Bourguet]

Ce qui est difficile dans un benchmark, ce n'est pas de mesurer des differences, c'est de s'assurer qu'elles sont pertinentes.

Ce que j'aimerai savoir, c'est si vous deviez apporter des améliorations du code du TriBulle donné, que feriez vous ?

Je n'utiliserais pas un tri a bulle.

[gbdivers]

Ce qui est difficile dans un benchmark, ce n'est pas de mesurer des differences, c'est de s'assurer qu'elles sont pertinentes.

La pertinence d'une mesure est lié à une question à laquelle la mesure tente de répondre. Donc ok, à la question "c++ vs d'autres langage", ce benchmark n'est pas pertinent (mais peut être que ce benchmark est pertinent pour la question "si le développeur lambda implémente un algorithme en c++ vs d'autres avec les outils par défaut qu'il a à disposition par exemple sur linux, quel langage serait le plus efficace")

Mon interrogation n'est pas là.
Ce qui m'intéresse est quel est ce "quelque chose" qui fait que ce benchmark est non pertinent ? Qu'est qu'on mesure réellement ?
Si le code n'est plus optimisable, c'est un problème de qualité du code généré par le compilateur. Qu'est ce qui change dans ce code généré par les différents compilateurs ? Comment contourner ce problème chez g++ par exemple (si c'est possible) ?

Je n'utiliserais pas un tri a bulle.

Naïvement (encore, je suis très naïf), je dirais que ça ne fait que déplacer le problème (sauf si bien sur on compare un tri par bulle en java avec un quick sort en c++... mais ça serait encore moins pertinent). A moins que le tri par bulle est naturellement plus efficace en java qu'en c++. Mais dans ce cas, que fait le compilateur java + jvm pour optimiser cet algorithme mieux que g++ ?


Bon, je mets ce post en résolu. Je crois que je n'aurais pas d'autres réponse que "ce benchmark n'a pas de valeur", sans savoir comment corriger/améliorer les choses.

Merci de vos réponses

PS :

pour n'importequel algo et n'importequel langage, tu peux via mauvaise foi classer les dits langages dans l'ordre que tu veux.

Le rédacteur de ce document développe en Delphi et enseigne le C++. Je ne crois donc pas que son propos était justement de mettre volontairement "de mauvaise foi" le java et c# devant le c++.
Sois plus didactique : s'il venait te voir pour demander conseil sur comment mettre en place ce type de benchmark, que lui dirais-tu de changer ? Juste le compilateur ? (parce que pour le développeur lambda = moi, prendre par exemple icpc sans le maîtriser n'améliore pas les performances)

[jblecanard]

Je vais faire des essais avec gcc et je te dirais si j'ai des résultats concluants.

Sinon, il ne faut quand même pas oublier qu'il y a un niveau où les performances seront "incompressibles", quand bien même c'est optimisé au mieux.

[gbdivers]

Bon, pas mieux avec icpc (dernière version, téléchargé hier) en testant avec différentes options de compilation (sauf avec -openmp, j'ai de meilleurs performances, mais forcement on ne compare plus la même chose). icpc fait pas mieux que g++ dans ce cas.

Je vais continuer à essayer de comprendre ce qui se passe "derrière" et je verrais bien par la suite.

Sinon, il ne faut quand même pas oublier qu'il y a un niveau où les performances seront "incompressibles", quand bien même c'est optimisé au mieux.

Sauf à passer par une machine virtuelle ? Parce que si on ne peut pas améliorer les performances du code c++ pour être plus efficace que du code java avec jvm, je ne comprend plus.
Pour moi, le coût de la généricité (ie avoir un langage compilé qui fonctionne sur toutes les plateformes en passant par une machine virtuelle) a forcement un coût en terme de performance. Mais je me trompe peut être.


PS :
Hors cette question spécifique, un point qui me dérange sur l'argumentation, c'est son absence.

Je sais que vous êtes pour la plupart des experts (ou au mieux, si le terme vous dérange, plus compétent que moi en c++) mais comprenez ma situation (qui est peut être aussi celle des lecteurs de ce document ou pire, des détracteurs du c++) :
je trouve un benchmark sur internet, je me dis que le code doit pas être optimum donc je regarde pour améliorer le code et compiler avec les bonnes options (ou plus précisément, celles que je connais) et je n'arrive pas à être plus performants que le programme java donné (en supposant la bonne fois du développeur et qu'il ne s'est pas amusé à donner les binaires java d'un code qui fait autre chose).
A part les conseils sur le compilateur (qui a permis de gagner en performance mais sans égaler le java), je n'ai droit qu'a un argument d'autorité : "le benchmark n'est pas valide". Mais je sais que si quelqu'un d'autre lit ce document et me dit "tiens, regarde, le java est mieux que le c++", je n'aurai aucun argument à donner : pas de benchmark allant dans le sens contraire, pas de test montrant que ce benchmark ne mesure pas la même chose, pas d'explication à ce résultat. Et pourtant, j'aurais essayé, en toute mauvaise foi, de montrer que le c++ est plus performant.
Comme je sais que j'ai encore beaucoup à apprendre en programmation (et que je suis un fervent défenseur du c++), je vais me contenter de cette réponse pour le moment, mais j'ai quand même une impression "qu'il y a quelque chose qui cloche".

[Klaim]

Est-ce que quelqu'un peut poster le code sur ce forum ou autre part (eventuellement directement les fichiers non zipés sur une page web)? Je n'arrive pas a récupérer le zip, le proxy de la boite ou je bosse dit qu'il ne passe pas le test antivirus (faites peut-être une verification...)

Je suis en train de me dire (sans avoir vu le code) qu'il doit y avoir des allocations/déallocations inutiles... N'importe quel algo tiré des autres languages deviennent naifs quand on ne tiens pas compte de l'agencement en mémoire en C++. Je peu me tromper, faudrait que je vois le code...

[Jean-Marc.Bourguet]

Donc ok, à la question "c++ vs d'autres langage", ce benchmark n'est pas pertinent

Je n'en sais rien. J'ai pas regarde et je ne fais pas confiance a priori a l'auteur original s'il n'a pas ete capable de compiler en optimise. Et je ne me fais pas confiance pour etre capable de sortir quelque chose de significatif de Java, je commettrais exactement le meme genre d'erreur.

A priori je m'attends au meme temps pour ce genre de chose entre Java et C++. Si ce n'est pas le cas - que ce soit dans un sens ou dans l'autre -- je chercherais d'ou vient la difference pour voir si c'est fondamental, lie a l'implementation, un effet de bord de quelque chose de non significatif...

[gbdivers]

voici les cpp (le zip ne passe pas)