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
- Computer Language Shootout (48 clics)
- ScoreCard (11 clics)
# Sympa comme page
Posté par harbort . Évalué à 10.
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 !
[^] # Re: Sympa comme page
Posté par zeDek . Évalué à -3.
# Précisions et compliments
Posté par Baptiste SIMON (site web personnel) . Évalué à 9.
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 Moby-Dik . Évalué à 0.
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 reno . Évalué à 7.
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 Benoît Sibaud (site web personnel) . Évalué à 10.
- 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 Nelis (site web personnel) . Évalué à 10.
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 François B. . Évalué à 9.
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 reno . Évalué à 4.
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 Sébastien Koechlin . Évalué à 9.
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 Luc Bourlier . Évalué à 2.
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 reno . Évalué à 3.
> 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 Nelis (site web personnel) . Évalué à 3.
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 Luc Bourlier . Évalué à 2.
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 outs . Évalué à 4.
>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 Marc (site web personnel) . Évalué à 1.
http://lampwww.epfl.ch/scala/(...)
# Manque un language
Posté par PloufPlouf (site web personnel) . Évalué à 1.
en terme de perf je suis sûr que ca serait pas loin du top du classement :-)
nan ?
[^] # Re: Manque un language
Posté par Moby-Dik . Évalué à 8.
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 Fabimaru (site web personnel) . Évalué à 1.
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.
[^] # Re: Difference C/C++ gcc/g++
Posté par Vivi (site web personnel) . Évalué à 2.
en C99, oui
# c'est quoi cette news à 0.3EUR ?
Posté par Dugland Bob . Évalué à 0.
Il n'a rien de nouveau ni d'extraordinaire.
# Stats sur les langages
Posté par Philippe F (site web personnel) . Évalué à 6.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.