"The Great Computer Language Shootout" Divers langages et compilateur au banc d'essai

Posté par (page perso) . Modéré par Benoît Sibaud.
Tags : aucun
0
23
mai
2002
Technologie
"The Great Computer Language Shootout" est un test d'un grand nombre de langage de programmation à l'aide de divers tests.
Il propose un classement des langages en fonction de l'utilisation du CPU et la mémoire lors de divers benchmarks.

Un classement global est proposé, vous permettant même de pondérer les différentes évaluations en fonction du type de traitement qui vous intéresse.

Le haut du classement selon leur pondération par défaut :
C (Gcc), Ocaml (Ocaml), SML (mlton), C++ (g++), SML (smlnj), Common List (cmucl), Scheme (nigloo), Ocaml (ocaml), Java (java), Pike(pike), Forth (gforth), etc ..

Note du modérateur : « Warning! This page is *just for fun* :-) »

Aller plus loin

  • # Sympa comme page

    Posté par . Évalué à 10.

    Dommage qu'il manque des langages comme le prolog !

    En effet, c'est surtout pour les langages specifiques qu'il peut etre interessant d'avoir ce type de page !
    Quand est-il interessant d'utiliser Prolog, Perl, LISP, ... ? Pas toujours evident d'y repondre, surtout quand c'est plus la rapidite/facilite de developpement que les performances qui comptent !

    Je vais de ce pas envoyer un mail au gars qui fait ce site web !
  • # Précisions et compliments

    Posté par (page perso) . Évalué à 9.

    « Warning! This page is *just for fun* :-) »
    Cela ne concerne que le second lien ScoreCard... Le premier semble être très sérieux. Vous me contredirez dans le cas contraire.

    Sinon, pour le premier lien, je tenais à souligner l'importance dans le choix de son langage de développement au début d'un projet. Le temps d'exécution de certaines opérations est un critère d'une grande importance. Grâce à ces résultats (qu'il faut savoir interpréter proprement), on peut se faire une opinion a priori. Beau travail donc. Cela risque de faire économiser du temps et de l'énergie à bon nombre de projets.

    Cela dit, il ne faut pas se limiter aux performances d'exécution. Celles-ci peuvent être un facteur critique, mais cela n'en est pas toujours à ce point. La syntaxe d'un langage (qui induit une qualité de lisibilité du code -si les développeurs sont rigoureux-) et les librairies disponibles, etc... sont aussi déterminants.
    <!troll | justeSuggestion>En effet, si vous souhaitez faire du prototypage sur un protocole réseau, il pourra être intéressant de le faire en java, alors que l'implémentation finale en C, python (?) ou autre pourra peut-être plus performante...</!troll>
    • [^] # Un peu falot mais...

      Posté par . Évalué à 0.

      En effet, si vous souhaitez faire du prototypage sur un protocole réseau, il pourra être intéressant de le faire en java, alors que l'implémentation finale en C, python (?) ou autre pourra peut-être plus performante...

      Excelllllent comme troll :)
      Surtout, on se demande en quoi faire un prototype en Java est plus facile qu'en C (sauf si bien sûr on ne maîtrise pas ce dernier) ! Franchement si tu veux faire un prototype vite fait de bidule réseau, prends un langage de scriptage offrant l'API désirée, après le choix dépend de tes goûts perso (Perl, Python... ou je ne sais quoi d'autre).
  • # Sympa ce comparatif

    Posté par . Évalué à 7.

    Cela permet de voir les forces/faiblesses des languages en performance/occupation memoire.
    J'ai deja lu ce comparatif il y a quelques mois, et c'est vraiment interressant pour comparer les performances et les besoins memoire..

    Bien sur, les performances ne sont pas tout:
    1) suite a lecture du comparatif, j'ai voulu apprendre Ocaml (il y a un livre en Francais disponible sur le web).
    Mais j'ai fait un rejet d'Ocaml: je n'ai vraiment pas l'esprit fonctionnel.

    Pour moi c'est encore moins lisible que du Perl (c'est dire)..
    --> Ruby ou Python?
    Mmmm, mon coeur balance :-)

    2) Java a beau etre un des languages interpretes les plus rapides du comparatif (par contre cote occupation memoire c'est beaucoup moins bien).
    Tant qu'il aura des problemes comme ca: http://www-106.ibm.com/developerworks/java/library/j-dcl.html?loc=j(...)
    je ne suis pas pres de me remettre a Java: beaucoup trop de bugs dans les librairies standards!
    • [^] # Re: Sympa ce comparatif

      Posté par (page perso) . Évalué à 10.

      Il serait surtout bon que la communauté s'investisse plus dans le Java libre :
      - JVM libres : ORP, kissme, Kaffe, Japhar
      - bibliothèques standards : Classpath, Classpathx
      - GCJ, Jikes
      - Mauve pour tester tout ça
      - et des bibliothèques sympas : JSX (GPL) pour la sérialisation <-> XML, Piccolo (LGPL) pour l'XML, Lumberjack (LGPL) pour loguer, etc.

      http://www.debian.org/doc/manuals/debian-java-faq/(...)
      « the SCSL is "about as free as the former Soviet Union" »
    • [^] # Re: Sympa ce comparatif

      Posté par (page perso) . Évalué à 10.

      Java a beau etre un des languages interpretes les plus rapides du comparatif (par contre cote occupation memoire c'est beaucoup moins bien).
      Tant qu'il aura des problemes comme ca: www-106.ibm.com/developerworks/java/libr
      je ne suis pas pres de me remettre a Java: beaucoup trop de bugs dans les librairies standards!


      Je ne vois pas le rapport entre l'article vers lequel tu pointes et les bugs dans les librairies standards ... Je ne dis pas que Java n'a pas de bugs dans ses librairies, il y en a des tonnes comme sans doute dans QT ou la libc ... Mais rien qui ne rende Java inutilisable, loin de là, je ne programme qu'en Java depuis deux ans et aucuns bugs ne m'a jamais empêché de faire quelquechose ... Quant au problème du double-checked locking, comme il est dit dans l'article ce n'est pas un bug, mais un comportement dû au modèle de mémoire utilisé dans Java. Et la solution est toute simple tu n'as qu'à déclarer toute ta méthode getInstance() synchronized ...
      • [^] # Re: Sympa ce comparatif

        Posté par . Évalué à 9.

        C'est vrai qu'aujourd'hui, avec les dernières JVM, il n'est plus utile d'avoir recours au double-checked locking étant donné que le coût des blocs synchronized a fortement baissé.

        Lorsque j'ai entendu parler de ce problème, j'ai voulu voir si devoir faire deux tests ne faisait pas perdre le temps gagné en ne passant pas dans un bloc synchronized. Résultat des courses avec la JVM 1.4, que ça soit en interprété ou avec hotspot (client et serveur) : laisse tomber, c'est quasiment la même chose. Donc autant déclarer toute la méthode synchronized.

        De plus, une petite recherche dans la base de données de bugs chez SUN montre qu'il n'existe aucun bug ouvert ressemblant à ça ... Il a probablement été résolu (du moins pour la JVM de SUN) : http://search.java.sun.com/Search/java?qt=+%2Bstate%3Aopen+%2B%22do(...) (il faut être enregistré (gratuit) sur le JDC pour accéder à cette page)
      • [^] # Re: Sympa ce comparatif

        Posté par . Évalué à 4.

        >Je ne vois pas le rapport entre l'article vers lequel tu pointes et les bugs dans les librairies standards.

        Exact, l'article parle de bug de JVM, mais en plus il y a des bugs de la librairie standard.
        En 98 j'ai essaye d'utiliser Java (surtout Swing)
        --> degoute.
        En plus Sun met un temps dingue pour les corriger ses bugs: il faut compter 2-3 ans pour des bugs pour lesquels des milliers de personnes ont vote dans la BugParade..

        > Mais rien qui ne rende Java inutilisable, loin de là,
        Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.

        > Quant au problème du double-checked locking, comme il est dit dans l'article ce n'est pas un bug, mais un comportement dû au modèle de mémoire utilisé dans Java.

        Mouais c'est une drole de feature quand meme!
        Ca, plus le fait que l'affectation d'un long est non-atomique suivant les JVM.
        Il peut tres bien affecter les 32-bits de la partie haute puis etre interrompu et ensuite seulement affecter la partie basse.
        Cf le meme site.

        > Et la solution est toute simple tu n'as qu'à déclarer toute ta méthode getInstance() synchronized ...

        Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!
        Le deboguage d'application multi-threadee avec des comportements aussi bizarre des JVM doit etre coton..
        • [^] # Re: Sympa ce comparatif

          Posté par . Évalué à 9.

          Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!

          C'est ridicule, si on n'est pas capable de voir qu'il va y avoir un problème d'accès concurrent dans ce cas trivial, il ne faut pas espérer produire des applications multi-threads, ça n'a rien de propre à Java.

          En 98 j'ai essaye d'utiliser Java (surtout Swing) --> degoute.

          Je suis tout à fait d'accords avec toi, Swing est une horreur, en 2002, ce n'est toujours pas résolu. Les machines ne sont toujours pas suffisement puissantes pour faire tourner ces usines à gaz de manière aussi fluide qu'une appli gtk ou qt. IBM a fait du beau boulot avec un truc bien plus léger écrit pour Eclipse.
        • [^] # Re: Sympa ce comparatif

          Posté par . Évalué à 2.

          > En 98 j'ai essaye d'utiliser Java (surtout Swing)
          ca fait 4 ans maintenant, ce qui est une duree relativement longue en infomatique, Swing c'est beaucoup ameliore depuis, surtout avec la version 1.4.

          > Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.
          Pour ce qui est de l'impression des trucs non-triviaux, je ne pense pas que tu puisse faire beaucoup plus de chose avec la seulement la libc. Si tu veux imprimer des trucs complexe en C, tu utiliseras une librairie specifique, c'est la meme chose en Java.
          IHM, cf plus haut. Et sinon, AWT/Swing n'est plus la seule lib graphique dispo pour Java. IBM developpe SWT, une librairie graphique Java pour win32/motif/gtk/... qui utilise au maximun les widgets natif de la platforme, par opposition a Swing qui en emule la plus grande partie.

          En ce qui concerne la correction des bugs par Sun, je ne pense que ca prennent 2 a 3 ans en generale, meme si c vrai qu'ils ont l'air moins reactifs que la plupart des projets OSS.
          D'un aute cote, Il me semble que Sun propose son implementation comme une implementation de reference, pas comme la 'super-VM-Java-rapide-sans-bugs-de-la-mort-qui-tue', d'autre societes proposent des implemtations de la JVM, notament IBM avec deux version : une version de la 1.3.1 Sun modifie (corrige ?) et J9 qui est une implementation 'from scratch'. Il ya surement d'autre JVM disponible sur le marche, mais je ne les connais pas.


          Ceci dit, j'ai comme l'impression bizarre ce que tu ecris vient de 'on-dit', que tu n'as jamais reelement fait de developpement en Java (ou, pas depuis au moins 4 ans).
          • [^] # Re: Sympa ce comparatif

            Posté par . Évalué à 3.

            > Ceci dit, j'ai comme l'impression bizarre ce
            > que tu ecris vient de 'on-dit', que tu n'as
            > jamais reelement fait de developpement en Java
            > (ou, pas depuis au moins 4 ans).

            Faux, j'ai réellement développé en Java en 98 comme je l'ai dit.
            Une preuve? Dans le JDK1.1.7, il y avait un bug du ramasse-miette: quand un objet n'était référencé que par des références statiques il était détruit (cas classique lors de classe singleton).
            J'ai mis pas mal de temps à comprendre pourquoi mon programme se plantait aléatoirement à différent endroits!

            J'ai eu encore plus de problème avec les librairies standard (Swing surtout, mais pas uniquement).
            Je ne l'ai pas utilisé depuis 98, mais je surveille quand même les évolutions depuis et je maitiens: la correction de bug pour lesquels des milliers de gens ont votés prend reellement des années..
            :-(

            Sun est beaucoup plus intéréssé à rajouter des interfaces pour tout et n'importe quoi plutot que de rendre fiable ses librairies..

            Ceci dit apparemment le JDK 1.4 a apporté un mieux de ce coté la.

            J'ai vu l'annonce d'IBM pour SWT, je n'ai pas encore eu l'occasion d'essayer, mais cela me parait TRES interressant.
        • [^] # Re: Sympa ce comparatif

          Posté par (page perso) . Évalué à 3.

          Exact, l'article parle de bug de JVM, mais en plus il y a des bugs de la librairie standard.

          Trouve moi une librairie / machine virtuelle avec un minimum de code sans aucuns bug et fais moi signe ...

          En plus Sun met un temps dingue pour les corriger ses bugs: il faut compter 2-3 ans pour des bugs pour lesquels des milliers de personnes ont vote dans la BugParade..

          C'est clair que certains bugs trainent depuis longtemps mais on ne peut pas dire que Sun ne corrige pas les bugs, il y en a énormément de corrigés très régulièrement ...

          Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.

          Je dois avouer que je suis plutôt côté serveur, donc tu as sans doute raison, dans ces domaines peut être que les librairies standards montrent leurs limites ... Mais il y a peut-être d'autres librairies qui te permettent de faire ce genre de chose ?

          Mouais c'est une drole de feature quand meme!

          Ils ne disent pas que c'est une feature non plus, c'est juste un comportement induit par le modèle de mémoire de Java, et encore le problème ne survient que lorsque le code s'exécute sur des machines multiprocesseurs. Si ils avaient choisi un autre modèle de mémoire, peut-être un autre problème aurait surgit autrepart, tout modèle a ses avantages et ses inconvénients ...

          Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!
          Le deboguage d'application multi-threadee avec des comportements aussi bizarre des JVM doit etre coton..


          La programmation multithreads n'est jamais trivial et demande une très bonne connaissance des comportements de la machine (virtuelle ou non) sur laquelle on développe ... C'est un des domaines les plus complèxes du génie logiciel ...
    • [^] # Re: Sympa ce comparatif

      Posté par . Évalué à 2.

      Il y a un truc pas clair dans l'article que tu proposes.
      L'article est du genre "Attention, il y a des problemes dans le modele de java, c'est pas bien", mais l'auteur se base sur la version 1.2.1 de la JRE de Sun, qui a au moins 2 ans (et deux ans c'est long en info), et dit lui-meme que dans les version 1.3 de IBM et SUN, le deuxieme probleme est corrige.
      L'article a peut etre ete mis en ligne en mai 2002 mais les informations qui sont dedans ne m'ont pas l'air de tout premiere fraicheur (je vais d'ailleurs me fendre d'un commentaire sur leur site).

      Sinon, comme le dit nelis, je vois pas le rapport entre ces problemes et les bugs possible dans les librairies standards. Personnellement je programme pratiquement exclusivement en Java, et je n'ai jamais rencontre de bugs dans les librairies standards (ce qui ne veut pas dire qu'il n'y en ait pas, seulement que ce n'est pas des *gros* bugs qui empeche toute utilisation du language).
    • [^] # Re: Sympa ce comparatif

      Posté par . Évalué à 4.

      >suite a lecture du comparatif, j'ai voulu apprendre Ocaml
      >Mais j'ai fait un rejet d'Ocaml: je n'ai vraiment pas l'esprit fonctionnel.

      Le rejet au début c'est normal la facon de penser est tellement diférente ...

      Mais si tu t'accroche un petit peut tu verra que les outils que te proposent les languages fonctionnels sont *tres* puissant.
      Quelques petits exemples :

      - L'inférence des types : on ne définis jamais le type des variables (pas de définition et pas de typage de fonction non plus).
      Le type est déterminé par le compilateur (on dit inféré) grace aux opérations qui sont effectué dessus.
      Par exemple si on fais a+b le compilateur sait que a et b sont des integer car l'opérateur + ne s'applique qu'a eux.
      Alors évidement c'est tres différent du C (la language de base pour bcp d'entre nous) mais imaginez comme c'est cool de ne pas avoir à déclarer des milliard de trucs ni a utiliser des caractères comme en perl (style $variable ou @bidule) (j'espere que je dis pas de connerire pasque ca fais des annés que j'ai pas touché au perl)

      -La pleine fonctionnalitée : les fonctions sont des variables (presque) comme les autres. Grace à ça on peut définir des itérateur (des for améliorés) sur toutes les structures de donnés. Exemple : vous prenez l'itérateur do_list qui applique une fonction a tout les objet d'un liste, et vous pouvez faire :
      do_list (printf "%s") ma_liste;;
      et ca imprime toute la liste

      Alors évidement le revers de la médaille c'est que les compilos de ce genre sont généralement assez lents. A mon avis ceux qui l'ont programmé doivent être très fiers de leurs optimisations. C'est vraiment un tour de force de faire tourner ca plus vite que du C++.

      Et l'auteur du comparatif dis justement que la vitesse d'éxecution n'est pas tout : le temps de développement peut être aussi déterminant, et justement grace a la puissance d'Ocaml on peut avoir le beurre et l'argent du beurre =)

      Et puis programmer en fonctionnel même juste pour essayer je trouve que ça ouvre l'esprit a d'autre méthode et d'autre facon de résoudre les problemes.

      REHM Joris

      Pour ceux que ca intéresse : caml.inria.fr (en plus c'est francais)
  • # manque un langage

    Posté par (page perso) . Évalué à 1.

    Ben oui, il manque le Scala! superbe langage qui n'en veut
    http://lampwww.epfl.ch/scala/(...)
  • # Manque un language

    Posté par (page perso) . Évalué à 1.

    Il manque le pascal nan ?

    en terme de perf je suis sûr que ca serait pas loin du top du classement :-)

    nan ?
    • [^] # Re: Manque un language

      Posté par . Évalué à 8.

      Il manque le pascal nan ?

      en terme de perf je suis sûr que ca serait pas loin du top du classement :-)


      Pourquoi ? De toute façon la page teste autant les compilateurs / interpréteurs que les langages eux-mêmes (c'est pour ça qu'un langage comme ocaml, quoique logiquement peu performant - car manipulant des paradigmes assez différents de ceux compris par le processeur -, se retrouve en haut du tableau car des types se sont cassé le crane pour l'optimiser correctement).

      De plus, les résultats ont l'air assez peu fiables (un programme identique en C et C++ qui retourne des temps d'exécution respectifs présentant une différence importante...). Du coup si l'on observe quelques dizaines de % de différence entre deux langages, ce n'est pas significatif ; par contre quand on voit que, sur des programmes identiques et écrits rigoureusement de la même façon, PHP4 est trois fois plus lent que Perl, on se dit que Zend feraient bien d'optimiser leur p... de machine virtuelle ;(


      nan ?
      • [^] # Difference C/C++ gcc/g++

        Posté par (page perso) . Évalué à 1.

        Deja, les programmes ne sont pas les meme. Si celui special C est plus rapide, je prendrais celui-la avec g++, puisque le C++ est quasiment compatible avec le C.

        Question: le mot-clef "inline" c'est standard en C (je fais du C++, pas du C) maintenant (je ne suis pas les normes) ? Parce que l'auteur l'utilise pour les programmes gcc.
  • # c'est quoi cette news à 0.3EUR ?

    Posté par . Évalué à 0.

    C'est un lien que je file régulièrement à ceux qui me gonflent avec les perfs du C/C++ dans les commentaires de linuxfr.
    Il n'a rien de nouveau ni d'extraordinaire.
  • # Stats sur les langages

    Posté par (page perso) . Évalué à 6.

    C'est marrant parce que hier, j'ai regarde et trie les stats sur les projets heberges par sourceforge et annonce sur freshmeat. C'est interessant.

    A gauche, le nombre de projets, a droite le langaage.

    Sourceforge:
    7715 C
    6889 C++
    5311 Java
    3872 PHP
    3331 Perl
    1621 Python
    778 Visual
    734 Unix
    667 Assembly
    616 Other
    611 JavaScript
    605 Delphi/Kylix
    507 Tcl
    443 PL/SQL
    218 ASP
    209 C#
    186 Lisp
    179 Objective
    155 Pascal
    131 Ruby
    115 Assembly
    110 Scheme
    96 Object
    73 ML
    67 Zope
    55 Cold
    54 Fortran
    49 Eiffel
    47 Prolog
    45 Ada
    39 Forth
    32 Smalltalk
    19 Rexx
    18 Erlang
    12 PROGRESS
    11 XBasic
    10 REBOL
    8 Pike
    6 APL
    5 Euphoria
    4 Logo
    0 Simula
    0 Modula
    0 Euler


    Freshmeat:
    5 Rexx
    5 Smalltalk
    6 Erlang
    7 C#
    7 Object
    8 Basic
    8 Forth
    8 Visual
    10 Cold
    13 ASP
    13 Haskell
    14 Emacs-Lisp
    17 Eiffel
    20 Zope
    22 Pascal
    23 Awk
    23 ML
    26 Delphi
    26 Fortran
    27 Ada
    39 PL/SQL
    46 Lisp
    46 Objective
    54 Other
    54 Scheme
    58 Ruby
    121 Assembly
    126 Other
    128 JavaScript
    199 SQL
    283 Tcl
    389 Unix
    684 Python
    1229 PHP
    1386 Java
    1565 C++
    2083 Perl
    3926 C

Suivre le flux des commentaires

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