Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par 3DArchi
19 commentaires

89PARTAGES

4  1 
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

Une erreur dans cette actualité ? Signalez-le nous !

19 commentaires
Poster une réponse Signaler un problème
Franck SORIANO
Avatar de Franck SORIANO
Expert confirmé https://www.developpez.com
Le 20/06/2011 à 23:31
Citation Envoyé par Willy_XIII Voir le message
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.
6  1 
Franck SORIANO
Avatar de Franck SORIANO
Expert confirmé https://www.developpez.com
Le 21/06/2011 à 13:04
Citation Envoyé par Willy_XIII Voir le message
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.

Citation Envoyé par Willy_XIII Voir le message

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é.
2  0 
Gouyon
Avatar de Gouyon
Membre éprouvé https://www.developpez.com
Le 22/06/2011 à 8:12
Citation Envoyé par Franck SORIANO Voir le message

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.
2  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
Le 20/06/2011 à 12:57
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.
2  1 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
Le 23/06/2011 à 11:18
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...
1  0 
Franck SORIANO
Avatar de Franck SORIANO
Expert confirmé https://www.developpez.com
Le 19/07/2011 à 22:02
Citation Envoyé par JCB001 Voir le message

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.

Citation Envoyé par JCB001 Voir le message

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.
1  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
Le 20/07/2011 à 0:25
Et il me semble que l'auteur de CPPCMS avait aussi fait un benchmark pour confirmer ce que tu expliques aussi.
1  0 
Voïvode
Avatar de Voïvode
Membre émérite https://www.developpez.com
Le 20/06/2011 à 12:17
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.
1  1 
développeur2013
Avatar de développeur2013
Candidat au Club https://www.developpez.com
Le 22/06/2011 à 21:25

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)
0  0 
développeur2013
Avatar de développeur2013
Candidat au Club https://www.developpez.com
Le 22/06/2011 à 21:29
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
0  0 
Poster une réponse Signaler un problème