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, Rédacteur
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de développeur2013 développeur2013 - Candidat au Club http://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)
Avatar de développeur2013 développeur2013 - Candidat au Club http://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
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 23/06/2011 à 10:54
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é...
Avatar de Klaim Klaim - Membre expert http://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...
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 23/06/2011 à 12:13
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".
Avatar de JCB001 JCB001 - Membre du Club http://www.developpez.com
le 18/07/2011 à 14:04
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.
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur http://www.developpez.com
le 18/07/2011 à 16:16
Citation Envoyé par JCB001  Voir le message
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++.
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://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.
Avatar de Klaim Klaim - Membre expert http://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.
Avatar de white_tentacle white_tentacle - Membre émérite http://www.developpez.com
le 21/07/2011 à 20:20
Citation Envoyé par Franck SORIANO  Voir le message
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.
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 21/07/2011 à 21:06
Citation Envoyé par white_tentacle  Voir le message
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 !
Offres d'emploi IT
Ingénieur IOS/Android H/F
COOPTALIS - Nord Pas-de-Calais - Lille (59000)
Ingénieurs Etude et Développement JAVA/J2EE (H/F)
FOEDERIS - Rhône Alpes - Lyon (69000)
Profil BI
COOPTALIS - Languedoc Roussillon - Région Montpelliéraine

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil