C# versus C++ en vitesse d'exécution dans quels cas sont ils les plus rapides ?

Version imprimable

14/12/2015, 13h09
Victor Vincent

1 pièce(s) jointe(s)

C# versus C++ en vitesse d'exécution dans quels cas sont ils les plus rapides ?

C# versus C++ en vitesse d'exécution dans quels cas sont ils les plus rapides ?
David Bolton effectue un cas particulier de micro benchmark avec les deux langages

Généralement C++ est reconnu comme étant un des langages les plus rapide en vitesse d'exécution. David Bolton se présente comme un développeur expérimenté et il est le fondateur de la société Bespoke Programmers qui a longtemps travaillé avec les langages C# et C++. Dans une de ses publications, il s’est intéressé à la vitesse d’exécution de ces deux langages pour déterminer lequel était plus rapide que l’autre. Pour ce faire, il a écrit un programme en C++ qu’il a ensuite traduit en C# et comparé les deux versions du programme à leur exécution. La comparaison des temps d’exécution des deux versions du programme a montré que la version C# s’est exécutée deux fois plus vite que la version C++, ce à quoi il ne s’attendait pas. En effet, avec les nouvelles versions de C++, le langage est devenu beaucoup plus puissant avec des ajouts de nouvelles fonctionnalités. Celles-ci couplées au fait que C++ utilise des caractères codés sur 8 bits alors que C# utilise des caractères codés sur 16 bits, David croyait qu’il serait plus rapide à l’exécution. Cependant il s’est rendu compte que C# pouvait être aussi rapide, voire plus si on fait les bonnes optimisations.

Pour mieux nous faire comprendre, David nous fait entrer dans son code pour en expliquer le principe. Le programme en question, écrit en C++ crée un fichier texte générant automatiquement des cartes de poker représentées par deux caractères chacune (exemple : DP = Dame de Pique). Le programme lit ensuite les données de ce fichier et écrit le temps mis dans un autre fichier (10 caractères par ligne). Cela a pris 3.5 secondes au programme écrit en C++ pour finir de lire le fichier entier qui contient la représentation d’un million de cartes. La version C# du même code a pris seulement 1,7 seconde pour s’exécuter soit une vitesse d’exécution deux fois plus grande que la version C++.

On ne peut cependant pas déduire une généralité pour une comparaison en se basant sur ce seul micro benchmark comme il semble vouloir le faire penser, pouvez-vous expliquer pourquoi vous êtes de son avis, ou d'un avis contraire ?

Pièce jointe 195220

Sources : Code source sur github & Article sur Dice

Et vous ?

:fleche: Pensez-vous que C# peut être parfois plus rapide dans certains cas que C++, ou dans quels cas C# peut être plus rapide que C++ d'après votre expérience personnelle ?
:fleche: Avez-vous des benchmarks ou des micro benchmarks à proposer qui montrent dans quel cas C++ ou C# sont les plus rapides ?

Voir aussi

:fleche: le forum Langage de programmation

:fleche: la rubrique générale Développement
14/12/2015, 13h40
Grimly

Ou comment dire autrement que :
- Le compilateur C# se base sur un ensemble de librairies qui sont optimisés pour bon nombre de processeurs.
- Lancer la compilation d'un projet C++ sans les options d'optimisations peux ne pas fournir les meilleurs performances.

Si on part sur ces mêmes principes, on peux dire que Java est plus rapide que C.
14/12/2015, 13h41
benjani13

Citation:

Cela a pris 3.5 secondes au programme écrit en C++ pour finir de lire le fichier entier qui contient la représentation d’un million de cartes. La version C# du même code a pris seulement 1,7 seconde pour s’exécuter soit une vitesse d’exécution deux fois plus grande que la version C++.

Ce serait peut être plus intéressant de faire des tests autre que de la lecture de fichier (qui dépend donc du temps d’accès au disque). Ou alors on ne parle pas de ces langages dans leur globalité mais juste de leur gestion des fichiers.
14/12/2015, 13h45
laerne

Quand est-ce que les programmeurs arrêterons de faire un programme écrit par une personne éxécuté une fois ou presque sur une machine et s'écrier X est plus rapide que Y!

Non pas que je doute du résultat, il y a surement des optimisations dans une vm qui permette d'éviter de la redondance, mais utilisons un échantillon un minimum significatif avant de sortir des conclusions.
14/12/2015, 13h46
grunk

Les sources :
Code : https://github.com/David-H-Bolton/PokerEval
Article : http://insights.dice.com/2015/12/09/...h-c-for-speed/

Suis pas expert de l'optimisation C++ , mais dans les commentaires de l'article pas mal de lecteur explqiue que le code C++ est loin d'être optimisé.

Donc on peut sans doute conclure qu'il est plus difficile d'écrire du code performant avec C++ qu'avec C# mais de là à dire que C# est plus performant que C++ ...
14/12/2015, 13h49
Voyvode
Merci à grunk pour les sources. :ccool:

Apparemment, ce « développeur expérimenté » se contente de « s’étonner » sans même approfondir ou soumettre une hypothèse pour expliquer ce résultat « surprenant ».

Comparer du code managé avec du code compilé est toujours très délicat car :
- dans le premier cas, la machine virtuelle décharge en partie le développeur des détails techniques les plus fins de son programme,
- dans le second cas, au contraire, le développeur est entièrement responsable du fonctionnement de son programme. Les optimisations ne se font pas automatiquement et un mauvais choix d’options de compilation peut désavantager du binaire face à du bytecode.
[Précisions supplémentaires]
Après consultation des sources et des commentaires, les faiblesses du code C++ semblent être les suivantes :
1. La méthode std::getline est lente.
2. L’objet std::string n’est jamais modifié et pourrait être remplacé par la valeur qu’il encapsule.
3. Utiliser std::endl dans la boucle rend le cache inefficace.
4. return ToString() + " " + ValueStr[(int)handvalue]; contient une concaténation peu efficace.
5. Active par défaut, la synchronisation des flux C++ (iostream) avec les flux C (stdio) est inutile dans cet exemple et peut être désactivée pour gagner en performance.
14/12/2015, 14h16
mangobango

Comme d'autres l'ont dit, le code C++ est loin d'être optimal. Ce gars à l'air moins à l'aise que moi au C++ alors que ça fait trois ans que j'ai rien écris en C++.

Si ça révèle un truc c'est effectivement qu'écrire du code pas optimal en C++ c'est quasiment le comportement par défaut du langage (et les tutos n'aident pas, par exemple à bien comprendre les streams, le buffering etc...).

Daniel
14/12/2015, 14h23
fabien29200

C'est pourquoi ce genre de tests doit passer par du code modifiable par la communauté (car personne n'est expert dans tous les langages).

Comme l'avait fait TechEmpower pour des tests de langages serveurs Web.

Après, c'est clair que des perfs deux fois meilleures, il y a baleine sous gravillon.
14/12/2015, 14h27
tomlev

Citation:

Envoyé par Victor Vincent

:fleche: Pensez-vous que C# soit plus rapide que C++, d'après votre expérience personnel ?

Non, et pourtant je suis fan de C#.

C'est tout le problème des micro-benchmarks comme a fait l'auteur de l'article : c'est très difficile de comparer les choses de façon significative.

De ce que j'ai vu de son article (ici), il n'a pas l'air de donner le code C# équivalent, donc difficile de dire si ça fait vraiment la même chose.

Ensuite il prend un exemple plus basique : copier un fichier vers un autre. Et là il dit :

Citation:

So now it’s just a simple “read from the in stream” then “write to the out stream,” inside a loop. Running the C++ version took 2.39 seconds for all million rows. When I did the same using the StreamReader() and StreamWriter() classes in C#, it took just 0.11 seconds, over twenty times faster. Clearly the Windows stream I/O classes std::ifstream and std::ofstream are quite slow in comparison to those .NET stream classes.

Sauf qu'il oublie un petit détail : le cache du système de fichier ! C'est beaucoup plus rapide de relire un fichier qu'on a déjà lu il y a peu de temps.
14/12/2015, 14h33
Luckyluke34

Je ne comprends pas non plus la petite image "Why C# is better than C++". Sortir de tels jugements à l'emporte pièce sur la seule base de la rapidité d'exécution d'une implémentation précise d'un algo particulier, c'est soit de la provoc' gratuite soit la preuve d'une limitation cérébrale assez confondante.
14/12/2015, 14h43
Arnard

Moué au final ça compare choux et carottes, article useless, next :)

La seule conclusion à apporter à le lire serait : "C# est plus rapide que C++ dans la manipulation de fichiers", et comme le pointe tomlev, faut prendre en compte le cache. Quand on fait du benchmark, on exécute des milliers de fois pour avoir un éventail de valeurs.
14/12/2015, 18h13
David Evan

Bonjour,

Cet article me fait penser à un autre que j'ai récemment vu opposant PHP 7.0 à HVMM et sur lequel j'ai déposé un avis qui sera globalement similaire à celui-ci.

Ces chiffres ont-il réellement de l'importance ? Je vois souvent au détour du web certain cherchant en permanence à prouver que "ceci" est mieux que "cela".

Je pense sincèrement que ces articles montre une chose : La mise en concurrence de plusieurs produits, sur différents aspects (les performances dans le cadre des langages) tend à améliorer ces dits produits.

Après, soyons honnête : De débattre (en campant sur ces positions) de C++ ou C# lequel est le plus performant, est-il réellement utile ? Le monde logiciel s'améliore en permanence, et ça, c'est une excellente chose.

Amicalement,
14/12/2015, 18h33
guillaume07

Je test un use case particulier: i.e lecture/écriture dans un fichier et j'en déduit une généralité concernant la vitesse d'exécution de tel au tel language :aie:. C'est parfait.
14/12/2015, 18h40
nikau6

Citation:

Envoyé par grunk

Les sources :
Code : https://github.com/David-H-Bolton/PokerEval
Article : http://insights.dice.com/2015/12/09/...h-c-for-speed/

Suis pas expert de l'optimisation C++ , mais dans les commentaires de l'article pas mal de lecteur explqiue que le code C++ est loin d'être optimisé.

Donc on peut sans doute conclure qu'il est plus difficile d'écrire du code performant avec C++ qu'avec C# mais de là à dire que C# est plus performant que C++ ...

Après un rapide coup d'oeil sur le code, on peut déjà voir que les std::string sont passés par copies et non par références. Je me suis arrêté la. Pas besoin d'en voir plus. Le type ne maitrise visiblement pas le c++.

Edit : En fait, il écrit du C++ comme on écrit du C#.
14/12/2015, 18h46
stef-13013

La banane parfois ca ressemble... à un fruit, mais pas tout le temps.

Comprendrai jamais ce genre d'article d'un autre age.

A mon tour :
Aujourd'hui un test avec un résultat qui va vous laisser sur le c*** :
Le vélo dans Paris c'est plus rapide que la voiture (mais parfois non, mais souvent oui)

Demain : Python c'est lent

Après demain : PHP c'est nul

La semaine pro : Linux c'est génial, Windows c'est de la merde (et M$ c'est le mal)

:mouarf:
14/12/2015, 20h58
Metalman

Comme d'autres ont dit, il y a tellement de choses qui faussent les résultats...

1) L'ensemble C# & libs a-t-il un traitement autour des fichiers que C++ n'a absolument pas ? (genre bufferisation de fichiers/réduction du nombre de syscalls sous-jacents.......)

2) Quid du code ?... (et apparemment les passages par copie au lieu des réfs démontrent une méconnaissance totale des bases de la prog OU une volonté totale de fausser les perfs)

3) "un" test. Nan mais l'époque du benchmark en UN test c'est fini.

4) Il me semble que déplacer 8 bits "aujourd'hui sur des x64" est devenu plus complexe que déplacer 16 bits ou +.

5) "Plus de fonctionnalités" != meilleures perfs
Faut se calmer un peu avec ça... car c'est exactement la gué-guerre CISC/RISC...
Donc ses présomptions sont pas bonnes non plus.

Tient quelque chose de marrant...

On retrouve les ~3.5sec annoncées.
Code:

1 2 3 4 \PokerEval-master\Release> .\pokereval.exe Time to evaluate 19981 poker hands: 3.73136 \PokerEval-master\Release> .\pokereval.exe Time to evaluate 19981 poker hands: 3.72686
Mais... Si on commente le Sleep(1); qui traine dans EvaluateHand(PokerHand& Ph)...
Code:

1 2 3 4 5 6 7 \PokerEval-master\Release> cp .\result.txt result_sleep.txt \PokerEval-master\Release> .\pokereval.exe Time to evaluate 19981 poker hands: 0.0709808 \PokerEval-master\Release> .\pokereval.exe Time to evaluate 19981 poker hands: 0.0743642 \PokerEval-master\Release> diff (cat .\result.txt) (cat .\result_sleep.txt) \PokerEval-master\Release>
=> résultats identiques, j'ai pas creusé, mais le Sleep à l'air plus coupable que le langage...

Conclusion : quelque soit le langage, si on attend au lieu de faire les calculs, c'est lent.

14/12/2015, 22h02
TiranusKBX

en plus des commentaires des autres j'ajouterait que comparer un language optimisé pour windows avec un language générique fausse complètement la comparaison
15/12/2015, 09h17
youtpout978

Au niveau des perfs de c# vs c++, dans la plupart des cas c++ est devant tant que le code est maîtrisé et bien optimisé (et oui on en revient toujours aux compétence du dev à la fin), mais quid du net native qu'elles sont ses perfs vs d'autre langage compilé.
15/12/2015, 22h35
tomlev

Citation:

Envoyé par TiranusKBX

en plus des commentaires des autres j'ajouterait que comparer un language optimisé pour windows avec un language générique fausse complètement la comparaison

Le langage lui-même n'est pas optimisé pour telle ou telle plateforme ; il n'y a rien dans le langage C# qui soit spécifique à Windows. Après, le compilateur (et le JIT dans le cas de C#) va évidemment générer du code optimisé pour la plateforme cible, mais c'est vrai aussi bien pour C++ que pour C#.

Au final, ce "benchmark" démontre surtout qu'on peut très bien écrire du code lent même avec un langage qui est intrinsèquement plus performant. Et aussi qu'il est plus difficile d'écrire du bon code C++ que du bon code C#...
16/12/2015, 09h54
Luc Hermitte

C'est pas tant que cela soit difficile. Ce qui est difficile est de faire rentrer dans les cranes que ce n'est pas parce qu'il est possible de recevoir des arguments par copie qu'il faille le faire. Les gens sont fainéants et beaucoup se refusent à prendre par référence constante, même quand cela leur est enseigné et que c'est dans tous les exemples qu'ils voient.
Rien que ça améliore grandement les performances dans les codes du benchmark -- ne parlons bien évidemment pas du sleep qui a parfaitement sa place dans un benchmark, n'est-ce pas?

De fait les langages où les objets ne peuvent pas manipuler directement, mais au travers de références (qui sont elles copiées), sont plus newb-friendly pour les performances.

Autre chose de "difficile", c'est que le C++, on n'en fait pas en faisant comme on faisait dans les autres langages sans faire l'effort d'en apprendre les spécificités. Là, on a vraiment l'impression de voir des bout de codes copiés depuis des sources diverses vu les différences de style.
16/12/2015, 19h52
DonQuiche

Une remarque : il est absurde de comparer des langages, on ne peut comparer que des compilateurs.

Un jour des compilateurs JS/Python/Java produiront un code aussi rapide que les meilleures compilateurs C, c'est parfois déjà le cas. Mais il faudra pour ça une capacité d'analyse rivalisant celle des humains, ce qui est loin d'être insurmontable concernant l'analyse de code source.