jeudi 24 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Liens connexes

Dépêche modérée par

: Comparaison de neuf langages sur un micro-benchmark

Posté par patrick_g (page perso, ). Modéré le 10 janvier 2004.
Ce micro-benchmark de neuf langages porte uniquement sur les opérations mathématiques de base et n’est donc pas représentatif de la vitesse en conditions réelles.
Néanmoins il est intéressant dans la mesure où il permet de visualiser simplement la différence qui peut exister entre les langages compilés, les semi-compilés et les purement interprétés.

NdM : en effet, "benchmark" très peu représentatif. Les trolleurs s'en sont déjà donné à coeur-joie sur OSNews et SlashDot. À vous maintenant, c'est l'occasion de tester la montée en charge du nouveau serveur ;-)

> Lire la dépêche (69 commentaires, moyenne: 1,5).  

La comparaison porte sur :

Java 1.3.1
Java 1.4.2
C avec GCC 3.3.1
Python 2.3.2
Python avec Psyco 1.1.1
Visual Basic .NET
Visual C# .NET
Visual C++ .NET
Visual J# .NET

Cette article a suscité une avalanche de réactions sur le site d’OSNews ou il a été posté.

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.

[+] Re: Comparaison de neuf langages sur un micro-benchmark

Posté par kruskal () le 10/01/2004 à 15:44. (lien). Évalué à -5.

Java sapu saipalibreuh (tm)

Ocaml vaincra

--
République bananière -- Banana Republic

Re: Comparaison de neuf langages sur un micro-benchmark

Posté par tene (page perso, ) le 10/01/2004 à 15:46. (lien). Évalué à 2.

C'est un très beau bench... de test de CPU et de filesystem... autrement dit: plutôt inutile pour comparer les langages.

Tester une série d'opération arithmétique n'est pas intéressant (ça donne si les test sont bien fait, les mêmes résultat, ce n'est pas le cas ici pour les raisons suivantes au moins: différence de précision, emploi d'instruction cpu ou d'algo pour les calculs trigonométrique, ...), il aurait fallu comparer les structures de données, la gestion des string, etc...

Par exemple le test ne montre que peu de différence entre C++ (natif) et C#, un test sur un vector comparé à l'ArrayList de C# marquera la différence...

Tester l'io en écrivant des string est biaisé:
- tester le C++ avec fputs...?
- tester java et .NET avec leur string, qui ne sont pas que des tableaux de byte?

Enfin ce genre de test d'io se résume vite a tester la taille du cache...

Bref, ce bench nous apprend peut-être une chose: en effet java (et .NET) ne sont pas intrinsèquement lent, le JIT, assez logiquement produit du code aussi bon que le natif.

ps: si qq connaissant gcc avait une explication pour les diff de perf entre VC++ et gcc ce serait pas mal, parce que j'avoue ne pas comprendre, quelques % d'accord, mais là...?

[+] Re: Comparaison de neuf langages sur un micro-benchmark

Posté par BoB () le 10/01/2004 à 15:46. (lien). Évalué à -1.

Bon, je vais pas me lancer dans les trolls (enfin si, je vais en cacher un, mais il est moins facile).
Le rapport entre le premier et le dernier est de 40. En supposant que j'écris un programme qui ne fasse que du calcul, il suffirait de faire passer la complexité disons de o(n^3) à o(n^2), et paf! le programme écrit en python écrase celui écrit en C.

Je sais que des fois c'est impossible de diminuer la complexité, mais je m'en rend moi-même tout le temps compte que si je codais moins tête baissée, y'a toujours à gagner à ce niveau.

Bon, je suis que programmeur du dimanche, et il y a ici des bien plus compétents que moi pour dire ce qu'ils en pensent.
Personnellement, le C j'aime de moins en moins, je suis obligé de prendre une douche après tellement j'ai joué le porc. Mais bon, tout le monde ne peut pas apprécier un langage tel le Caml :op

[+] Re: Comparaison de neuf langages sur un micro-benchmark

Posté par TImaniac (page perso, ) le 10/01/2004 à 15:59. (lien). Évalué à -7.

J'ai personnelement fait un autre benchmark : les langages dit "de haut niveau" comme python sont censé apporter la simplicité et la clarté du code... Personnelement, je penses que le C# a le meilleur compromis entre perf et esthétique du code. Question de goût sans doute.

--
MonoFrance

Re: Comparaison de neuf langages sur un micro-benchmark

Posté par chl (page perso, ) le 10/01/2004 à 16:40. (lien). Évalué à 7.

Voici une comparaison de differents langages un peu plus complete quoi que plus tres a jour d'apres l'auteur :

http://www.bagley.org/~doug/shootout/index2.shtml(...)

[+] Oubli ?

Posté par Pierre Tramo (page perso, ) le 10/01/2004 à 17:00. (lien). Évalué à -4.

Ils ont oublié de citer dans leur bench le langage à la mode du moment : Templeet ! C'est dommage, car étant donné que pour les appli web il est plus rapide qu'Apache, je suis sûr que sur des opérations mathématiques ce langage fonctionnel aurait explosé les langages syntaxiques tels que le C++, voire même le C. J'espère qu'ils sortiront une nouvelle version pour corriger cette lacune.

Re: Comparaison de neuf langages sur un micro-benchmark

Posté par Vivi (page perso, ) le 10/01/2004 à 20:57. (lien). Évalué à 3.

Heh. quel sketch ce benchmark. Aucune info sur la variance des temps mesurés : vu les différences minimes qui sont parfois observées, ça n'a vraiment aucune valeur.

Garçon, y'a du code moisi dans mon verre de pipotron !

Posté par __caffeine__ () le 11/01/2004 à 01:32. (lien). Évalué à 8.

Mouarf... Faudrait déjà que le code soit plus soigneusement écrit...
Rien qu'en faisant une bête optimisation du fichier python (et pas un truc de l33t gourou, un truc qu'on trouve dans tous les articles un peu avancés sur python), je passe de 450 sec. à 300 sec. sur un vieux celeron 400 pour le bench trigo. J'ai pas regardé les autres fichiers, mais si c'est du même acabit...

Pour les ceusses qui veulent essayer, remplacez ça:




def trig(trigMax):



    startTime = time.clock()

    i = 1.0

    sine = 0.0

    cosine = 0.0

    tangent = 0.0

    logarithm = 0.0

    squareRoot = 0.0

    

    while i < trigMax:

        sine = math.sin(i)

        cosine = math.cos(i)

        tangent = math.tan(i)

        logarithm = math.log10(i)

        squareRoot = math.sqrt(i)

        i = i + 1.0


par ça:




def trig(trigMax):



    startTime = time.clock()

    i = 1.0

    sine = 0.0

    cosine = 0.0

    tangent = 0.0

    logarithm = 0.0

    squareRoot = 0.0

    mathsin = math.sin

    mathcos = math.cos

    mathtan = math.tan

    mathlog10 = math.log10

    mathsqrt = math.sqrt



    while i < trigMax:

        

        sine = mathsin(i)

        cosine = mathcos(i)

        tangent = mathtan(i)

        logarithm = mathlog10(i)

        squareRoot = mathsqrt(i)

        i = i + 1.0


C'est du python, attention à l'indentation...

Re: Comparaison de neuf langages sur un micro-benchmark

Posté par Snark_Boojum () le 11/01/2004 à 08:53. (lien). Évalué à 11.

Ce qui m'emmerde le plus dans ce genre de test, c'est que la comparaison des langages se fait par mesure... de vitesse d'exécution. Quelle connerie!

Le temps de développement est à considérer, par exemple: entre passer trois semaines pour écrire un truc super-rapide en assembleur et une minute à faire un shell script, il n'y a pas d'hésitation:
* si c'est pour obtenir un résultat qui ne sert qu'une fois et qui ne prendra que deux minutes à calculer par la voie lente, on choisit le script;
* si c'est une routine qui va être utilisée des millions de fois dans un programme qui va bien servir, on choisit l'assembleur.

La facilité de relecture est aussi à considérer: si vous savez que vous allez traîner un bout de code pendant une bonne décennie, et que les gens qui vont s'en occuper vont tourner (dans une SSII par exemple), il y a quand même un peu intérêt à ce que ce soit facile de s'y mettre, c'est pas grave si du coup il est un peu plus lent à exécuter ou écrire. Ca met dehors les langages genre assembleur, C et C++ (quoiqu'évidemment, avec dix lignes de commentaire pour chaque ligne de code, ça puisse être jouable).

Autre exemple de point à considérer: les garanties. Dans la plupart des langages, faire de la vérification de concordance entre ce que fait le code et ce que veulent les specs est une vraie galère, et basé sur des hacks (les "assertions"). Le seul langage que je connaisse qui fasse ça bien, c'est eiffel, avec ses pre-conditions, post-condition, son invariant. Car il y a des cas où on veut être sûr de son code: avion, pompe médicale, ...

Bref, vouloir "comparer" des langages rien qu'avec des "benchmarks" (et en plus, ici, "micro-" !), c'est d'un ridicule assez puissant.

Snark

Re: Comparaison de neuf langages sur un micro-benchmark

Posté par Antoine Duval () le 11/01/2004 à 17:03. (lien). Évalué à 4.

Et si on parlait un peu plus du temps humain nécessaire à développer un programme similaire dans ces neuf langages ?
Parce que franchement j'en ai rien a foutre de savoir si un prog met 10^-n sec à exécuter une instruction, sachant que au pire ces langages ont en comparaison de complexité une différence en 0(log(N)).
Par contre les langages où il est nécessaire de réinventer la roue à chaque fois (librairies absentes, mal documentées, absence de suivi de version, par exemple), moi ça gave ...

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.2496s (dont 0.0447 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.