C'est moi que j'ai la plus grosse !!
Par Fred le vendredi 23 novembre 2012, 15:26 - Développement - Lien permanent
Bien que ce soit la vérité, ce n'est pas de ce que tu crois, ô lecteur pervers et lubrique, que je vais parler.
Certes, il y a analogie mais je viens te parler ici et maintenant d'un site souvent fréquenté et peu critiqué... Pourtant, il mériterait de l'être.
Si c'est pas du teasing ça !!!
Ce site, c'est le Computer Language Benchmarks Game.
Les non-initiés disent déjà :
Cékoidonk ??
Simple, c'est une comparaison de langages de programmation pour des programmes identiques sur des machines identiques... Enfin, ça, c'est la théorie !
Regardons d'un peu plus près.
Déjà, ça part mal puisque quatre types de machines servent aux tests, leur différence étant sur le nombre de bits et le nombre de cœurs.
On peut se dire que déjà la phrase qui dit :
We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.
Va largement foirer quand on voit la différence qu'il y a entre penser un programme en mono-tâche ou en multi-tâche.
Toujours dans le programme Mandelbrot, si l'on y prête bien attention, on voit que le C ne possède rien que 7 entrées[1], l'Ada 3 et le C++ 8.
Diantre !!!! On peut donc écrire le même algorithme de 8 façons différentes ???
A part, en changeant le nom des variables et l'ordre de certaines lignes, c'est quand même chaud.
Alors qu'est-ce qu'il se passe ?
Prenons la version C arrivant en premier. Attention, ça va aller très vite
#pragma omp parallel for for (i = 0; i < N; i+=2) { v2df Crv = { (i+1.0)*inverse_w-1.5, (i)*inverse_w-1.5 }; Crvs[i >> 1] = Crv; }
C'est quoi ce pragma ? Et bien, c'est simple, il s'agit de l'utilisation d'OpenMP.
La question que l'on est en droit de se poser est :
Est-ce vraiment le même algo que la version
standarden C ?
D'ailleurs, elle contient quoi la version standard ?
for (i = 0; i < NWORKERS; i++) pthread_create(&ids[i], NULL, worker, NULL);
Des threads !!! Ben, ça fait pas non plus partie de la norme C tout ça.
Et en Ada, ça donne quoi ? Et bien, sur cet exemple-là, ça va mais ce n'est pas le cas de celui-là où on trouve, sans complexe
pragma Import (Intrinsic, "+", "__builtin_ia32_addpd"); pragma Import (Intrinsic, "*", "__builtin_ia32_mulpd"); pragma Import (Intrinsic, "/", "__builtin_ia32_divpd");
ou comment faire des appels système non prévu dans le langage[2].
Bon, je ne vais pas décortiquer tous les exemples mais cela reflète bien la guerre sainte des langages.
Malgré les consignes demandant de suivre le même algorithme, une grande partie du code fourni contient des éléments afin d'optimiser à mort le code, quitte à le rendre illisible, mais à gagner la guerre.
Ceci dit, après mon excellent ticket sur Ruby, je peux quand même dire que les langages de script sont à la ramasse mais c'est NORMAL !!!
On ne leur demande pas de la performance.
Commentaires
En tant que modeste contributeur au bench Alioth, j'aurais un jugement plus nuancé sur celui-ci.
Quant on regarde de plus près les différences de performances, on s'aperçoit que ces différences viennent souvent des bibliothèques utilisées.
Par exemple, sur regex, il y a des bibliothèques avec compilation Just-in-Time, qui sont plus performantes que des bibbliothèques regex statiques.
Ceci étant, on voit clairement qu'Ada est plus peformant que Java, tant pour la vitesse que pour la consommation mémoire.
Ada est plus verbeux mais pour des raisons de lisibilité.
@baskerville :
J'ai été volontairement provocateur dans ce billet, comme souvent :D
Ceci dit, dans un esprit fair-play, il eut été normal qu'il n'y ait qu'une seule version du programme pour chaque langage et que l'algorithme reste strictement le même. Si cela avait été le cas, les résultats en auraient été moins sujet à controverses.
Le seul écart tolérable, car inévitable, vient des différences de paradigme car on ne peut demander à un langage fonctionnel d'appliquer à la lettre l'algorithme qui est, la plupart du temps, décrit de façon procédural.
J'aime quand même bien faire un tour régulièrement pour voir les résultats mais, comme pour tout benchmark, ils sont à relativiser. Ensuite, pour ce qui est de voir des exemples d'un même algorithme dans différents langages, je préfère le Rosetta Code car on y trouve du code bien écrit sans le souci de . Pour les codes ultra-orientés perfos, c'est clair que le Benchmarks game est nettement mieux mais comme dit notre ami Knuth :