samedi 11 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Langages et performances : les Français à l'honneur !

Posté par Lionel Draghi (page perso, ). Modéré le 19 mai 2005.
0
Pour nourrir les débats sans fin sur les performances relatives des langages, voici une source de données bien faite : The Computer Language Shootout Benchmarks.

Le dernier site similaire n'étant plus mis-à-jour depuis 2003, Brent Fulgham a repris le flambeau, et s'est installé sur un serveur Debian.

Ce site permet de soumettre des benchs, de proposer des réalisations de ces benchs pour un langage, et surtout de consulter les résultats sous différentes formes (y compris graphiques) suivant différents critères (en particulier CPU et utilisation mémoire).

La base des résultats actuels est bien remplie, de nombreux langages et compilateurs y figurant avec un bon nombre de benchmarks (il n'est pas nécessaire de tous les réaliser pour figurer dans le classement).

Surprise, juste derrière un C à la domination chancelante, figurent trois technologies dans lesquelles les Français jouent un rôle important (voire qui sont exclusivement française). Il s'agit respectivement de OCaml, Ada et Eiffel.

> Lire la suite (179 commentaires, moyenne: 2,5).   [dépêche : 3130 caractères]

Je ne rentre pas dans les détails de la participation française à la définition de ces langages, ou/et à la réalisation de ces compilateurs libres.

Parlons plutôt des langages eux-mêmes, dont les qualités mériteraient d'être utilisées plus souvent. J'espère que leur présence en tête de classement incitera plus de développeurs à la curiosité.

L'argumentaire usuel de ces trois langages se base plutôt sur une sémantique de haut niveau, sur des choix guidés par les besoins du génie logiciel, sur l'efficacité dans le développement, la portabilité, la qualité obtenue, etc. Les excellentes performances sont rarement évoquées. Et pourtant !

Étant donné que tous trois sont disponibles sur une large gamme de plateformes (CPU/OS), ce sont des alternatives à considérer, au moins en lieu et place de C : on peut utiliser un langage bien plus puissant sans rien sacrifier des performances.

Enfin, tous trois sont assez différents des langages "mainstream". Si vos neurones commencent à macérer dans le jus d'accolade, ils vous feront l'effet d'un chewing-gum fortement mentholé.

Notons que ce classement ne fait pas du bien à tout le monde : C++ est loin du peloton de tête, à tel point que Java fait presque aussi bien. C# s'en sort mieux en particulier en CPU. Quant à gcj, bon dernier des deux classements, soyons charitables : laissons lui encore quelques années pour arriver à maturité.

Vous trouverez certainement tous des résultats surprenants dans ces données. Qui aurait dit, par exemple, qu'Ada monterait sur le podium, avec un score quasiment double de C++ ? Je vous laisse faire votre marché aux conclusions. Je n'en suggère qu'une seule : méfions nous des préjugés !

Pour éviter les trolls trop faciles, je termine sur quelques précisions :

- tout d'abord, le bench est bien sûr sujet à discussions et interprétations interminables. Comme il est répété à plusieurs endroit sur le site de Shootout : "benchmarking without analysis is bogus". Il ne faut pas prendre les résultats au pied de la lettre.

- il faut bien identifier le besoin : les logiciels ont rarement besoin d'une empreinte mémoire optimisée, ou de performances aux stéroïdes. Il suffit de considérer la grande quantité de logiciels donnant pleinement satisfaction écrit dans les langages de script les plus populaires.

- il y a bien d'autres critères que les performances pour choisir un langage.
La liste des critères et leur pondération est à considérer à chaque développement (enfin bon, là je parle pour ceux qui font des choix rationnels :-). En bref, ne psychotez pas parce que votre langage favori n'est pas sur le podium.

- enfin, n'oublions pas que ce qui est évalué n'est pas le langage, mais le couple langage/compilateur. Bien que l'on puisse identifier immédiatement quelques caractéristiques du langage qui vont avoir une influence lourde sur les performances, il reste difficile de faire la part des mérites respectifs de la conception du langage et de l'optimisation du compilateur. Si le compilateur n'est pas déjà très bon, il reste une certaine marge de progression, les résultats peuvent changer.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Remarque...

Posté par Nico (page perso, ) le 19/05/2005 à 13:00. (lien). Évalué à 10.

A noter:

And remember, languages that implement more benchmarks will move to the top of the list, and those with many missing benchmarks will stay at the bottom!


Ca peut expliquer certains résultats, quand on voit qu'il manque 9 benchmarks sur le C, et que 3 sur Ocaml, 2 sur l'ADA, ou qu'il en manque 15 sur le C++ Intel...

Un petit test custom

Posté par iug () le 19/05/2005 à 13:46. (lien). Évalué à 5.

En ne sélectionnant que le sous-ensemble implémenté par tous les langages cités voilà le résulta :

1er C Intel 34
2eme C GCC 31
3eme Ocaml 22
5eme C# Mono 13
6eme Java 11

PS: inclure les C++ aurait néxessiter de désactiver trop de benchs

Ceux qui auront suivi/participé au troll Java v.s C# comprendront qu'ils feraient mieux de se mettre à OCaml s'ils cherchent un langage à la fois puissant et performant. Si tant est qu'on peut qualifier les deux derniers de puissant quand on les compare à OCaml lol.

interesting alternative programs

Posté par ufoot (page perso, ) le 19/05/2005 à 14:33. (lien). Évalué à 7.

> - il faut bien identifier le besoin : les logiciels ont rarement besoin d'une empreinte mémoire optimisée, ou de performances aux stéroïdes. Il suffit de considérer la grande quantité de logiciels donnant pleinement satisfaction écrit dans les langages de script les plus populaires.
mmm, j'ajouterai même que les aspects "il faut utiliser l'agortithme tralali tralala" pénalisent les langages qui utilisent les tournures idiomatiques et autres constructions particulières à gogo. Typiquement sur le 1er test (ackermann donc) faut quand même noter qu'à côté du gagnant:
OCaml 0.11 516 0.11 6
en 11 1/100èmes de secondes on trouve tout de même:
C gcc #2 0.07 10,656 0.07 54
C Intel #2 0.07 188 0.07 54
Perl #3 0.07 1,464 0.07 8
les 3 en 7 1/100èmes de secondes, ce qui est remarquable.
Ces dernières versions ne respectent pas à 100% la règle du jeu, mais quand même...

Après il est vrai que si on ne s'impose pas de suivre les mêmes algorithmes on risque de tester les algos plutôt que le langage lui-même. Moi j'aurais eu tendance à autoriser tous les coups. Mais l'approche du test est intéressante car au fond, l'expérience montre que ce qui fait souvent la lenteur des langages de script c'est qu'ils sont parfois utilisés "comme si c'était du C". Je veux dire par là que souvent la transition d'un langage en un autre se résume à un changement de syntaxe et ne s'accompagne pas (en tous cas c'est ma démarche naturelle si je ne m'impose pas de faire les choses "comme il faut") des changements de méthodologie, de paradigmes, qui sont pourtant essentiels.

Cela se traduit par exemple par "vas-y que je te fais un tri à la mimine avec un for 100% scripté" alors qu'il existe des constructions qui permettent de s'en débarasser en une ligne, avec un temps d'exécution divisé par 100. Cet aspect plombant les performances des langages de script dans le monde de la vraie vie, il n'est peut-être pas idiot que ça ressorte quand-même dans le test. Enfin bon pour un puriste tout de même on se dit que s'imposer de faire un programme en Perl en utilisant "cette méthode là et pas une autre" c'est vraiment marcher sur la tête. TIMTOWTDI qu'y disait.

Un peu fumeux...

Posté par Antoine () le 19/05/2005 à 14:35. (lien). Évalué à 3.

Le site Web le dit lui-même : ces benchmarks sont éminemment faillibles. D'abord ce sont tous des micro-benchmarks, des tests sans commune mesure avec l'échelle d'une application sérieuse. Ensuite la règle de chaque test est arbitraire, et peut favoriser certains langages par rapport à d'autres. Enfin, la plupart des tests interdisent d'utiliser des bibliothèques tierces, bien que celles-ci puissent quelquefois donner d'énormes améliorations.

Surtout, ce type de comparaison isole le temps d'exécution en ignorant un autre temps tout aussi important : le temps passé à écrire, débugger, maintenir un programme. Les utilisateurs de langages comme Python ne sont pas dupes, ils savent que le C est plus "rapide" à l'exécution... mais uniquement si on dispose de beaucoup de temps pour écrire un programme aussi soigné et bien conçu qu'on le ferait en Python.

« Are your programs even like these benchmarks?

* Do your programs startup and finish within a few seconds, like these benchmarks?
* Are your programs tiny, like these benchmarks?
* Do your programs avoid library re-use, like these benchmarks? »

http://shootout.alioth.debian.org/miscfile.php?sort=fullcpu&fil(...)

C comme les sondages ce truc :)

Posté par Bapt (page perso, ) le 19/05/2005 à 14:43. (lien). Évalué à 2.

C'est un peut comme les sondages ce truc : plein de chiffres qui ne veulent rien dire, des classements sur des bases non pertinentes, ...

Bref aucun des langages n'est testé à la même manière, pour certains, il manque plein de tests. Comparer des résultats sur un langage/compilo sans avoir effectué les mêmes/même nombre de test ça ne veut rien dire.

De plus, comment faire un truc pareil sans appeler au troll, genre ouais mais il a utilisé gcc 3.4.4 pou gcj alors qu'il y a la 4.0.0 qui est mieux ou inversement. Il a utilisé tels optimisations de compilation alors que pour ce truc, il aurait mieux valu tel ou tel option,il ne sait pas codé en tel langage, et a écrit sont truc comme une procasse, il aurait du coder la même de telle ou telle manière et mon langage aurait tout torcher.

Bref ces benchmarks ne sont aucunement significatifs et ne veulent rien dire du tout !!!

benchmarks bidons

Posté par TazForEver () le 19/05/2005 à 16:11. (lien). Évalué à 8.

je n'ai pas lu les modalités, mais quand je vois des comparaisons à coup de centièmes de millisecondes, je me dis que c'est pas très sérieux. Il faut des temps d'exécution de l'ordre de la minute pour commencer à avoir des résultats significatifs et que les "dérangements" extérieurs prennent une portion non-significative.

Ocaml va t'il remplacer C++?

Posté par salvaire () le 19/05/2005 à 16:53. (lien). Évalué à 4.

Ce qui est intéressant avec ce benchmark. C'est dévalué la perte de performance avec un langage de haut niveau.

Dans le domaine du calcule numérique en physique, C++ a remplacé Fortran. C++ est un langage oo rapide, mais c'est une horreur. Sa syntaxe est indigeste (surtout pour un physicien). L'introspection est beaucoup trop limité, pas de oo dynamique à la ObjectiveC. Le système d'arguments par défaut est une belle saloperie, vive les labelles. La stl est une aberration (code dans l'interface, code bloat). Il n'y a pas d'interpréteur valable. etc ...

Grâce à ce benchmark on peut voir qu'Ocaml semble peut pénalisant au niveau vitesse par rapport à C++. Je me demande bien qu'elle va être l'intérêt du C++ d'ici quelques années avec les processeurs 4 cores. Il y a 10 ans, on pouvait comprendre son design. Aujourd'hui, j'ai des doutes! Car mêmes en calcule intensif, le temps d'exécution est très relatif par rapport au temps cumulé d'écriture, de compréhension et de mise au point.

Dommage ...

Posté par Thomas Petazzoni (page perso, ) le 19/05/2005 à 17:59. (lien). Évalué à 10.

Salut,

Je suis un peu déçu par la rédaction de la news. En effet, elle insiste beaucoup sur l'aspect benchmark lui-même, sans ouvrir le débat plus large sur l'utilisation de langages de haut-niveau. Du coup, le débat tient plus du troll mon langage est mieux que le tien, non, c'est le mien qu'il est le mieux, etc... (trolls qu'on a déjà dans la news sur OpenOffice et Java).

Ce qui est intéressant, c'est de voir que les langages de haut niveau ne sont plus sous-performants par rapport à des langages comme le C de base. L'important, ce n'est pas de savoir si Ocaml s'exécute 0.5% plus vite que du Java ou du C++ dans tel cas précis, mais bien de voir que les performances globales des langages de haut niveau sont tout à fait honnêtes.

À partir de là, on pourrait se demander si il ne serait pas judicieux d'arrêter de développer tous les logiciels avec des langages préhistoriques comme le C. Je ne dis pas ça parce que je ne sais pas programmer en C (je bosse sur de la programmation système, donc que du C), mais parce que pour moi coder gkrellm, thunderbird ou grisbi en C, c'est une perte de temps. Des langages de haut niveau existent, ils rendent le code plus lisible, plus abordable pour des contributeurs et ils permettent d'éviter les bugs foireux de débordement de buffers, de mémoire pas libérée et autres. Pour moi, ces langages de haut niveau, c'est vraiment un atout pour le programmeur. Pourquoi ne pas les utiliser plus massivement pour toutes les applications de bureau ?

La performance ne me semble pas être la bonne raison : la plupart des logiciels "de bureau" ne font pas du calcul scientifique qui nécessite d'être optimisés aux petits oignons.

En fait, j'ai l'impression que pour l'instant, le langage C est pris parce que c'est le seul suffisamment répandu. Aucun langage de haut niveau n'a vraiment réussi à s'imposer : ni Ocaml, ni Eiffel, ni Java, ni C#.

Quand je vois Novell qui essaie d'utiliser C# et Mono dans ses nouveaux outils et logiciels, je trouve que c'est plutôt une bonne idée. Une bonne idée dans le principe d'utiliser un langage de haut niveau, mais on sait tous que C# et Mono peuvent peut-être poser des problèmes (pouvoir de Microsoft ? brevets ?).

Qu'en pensez-vous ? Pourquoi les applications sont-elles toutes développées en C ?

bidon

Posté par Roger Rabbit () le 19/05/2005 à 18:17. (lien). Évalué à 1.

Les tests sont assez marrants, je prends l'exemple d'un langage que
je connais bien, le Java. En rajoutant dans le test de ackermann une boucle,
on peut observer ceci

[rabbit speedball] time java -server ackermann 9 1
Ack(3,9): 4093
java -server ackermann 9 1 0.30s user 0.29s system 72% cpu 0.818 total

[rabbit speedball] time java -server ackermann 9 100
Ack(3,9): 4093... etc
java -server ackermann 9 100 5.39s user 0.33s system 61% cpu 9.267 total

[rabbit speedball] time ./ackermann.gcc_run 9
Ack(3,9): 4093
./ackermann.gcc_run 9 0.05s user 0.00s system 4% cpu 1.089 total

Qu'est ce que l'on voit ? que plus le code tourne et plus il est
efficacement éxécuté. Lancer le test 1 fois ne donne aucune
indication sur la rapidité de java ... ... tester une jvm "à froid"
donne toujours des résultats décevants