Comparaison de neuf langages sur un micro-benchmark

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
10
jan.
2004
Humour
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 ;-) 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é.

Aller plus loin

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  . Évalué à -5.

    Java sapu saipalibreuh (tm)

    Ocaml vaincra

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  . É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  (site web personnel) . Évalué à 0.

      Effectivement, la différence entre gcc et vc++ est bizzare, surtout avec le même code, et toutes les optimisations activées...

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  (site web personnel) . Évalué à 5.

      Ça pourrait être parce que -ffast-math n'a pas été utilisé pour gcc et que ça l'a empêché de mettre en oeuvre des optimisations qui pourraient dégrader la précision du résultat

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  (site web personnel) . Évalué à 8.

      > 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,

      Ben ça sert à quoi alors de compiler avec -O3 ?

      Bon, quand on dit qu'on benchmark un langage, en fait, c'est clair qu'on benchmark un compilateur et l'environnement d'execution, mais bon.

      Tu écrit

      x = y + z;
      t = x + w;
      a = b + c;

      Maintenant, tu as

      Déjà pour un langage interprêté, pour faire y + z, il faut faire un switch sur l'opérateur (voire un appel de fonction), voir que c'est un "+", puis l'executer. Donc, si tu as les mêmes performances en lisp interprêté et en C, y'a de quoi se poser des questions.

      Ensuite, est-ce que y et z sont passés par valeur ou par référence. En Java, si x et z sont des "Integer", il faut deux indirections de pointeurs. Ca coûte cher !

      En Ada, y + z fait un test de débordement et lève potentiellement une exception (sauf si tu l'as désactivé à la compilation), pas en C.

      Maintenant, entre deux compilateurs C.

      Tu as celui qui a géré n'importe comment ses registres, qui a mis y et z dans la mémoire, et puis celui qui a mieux optimisé ses registres, et qui a déjà y et z dans des registres. Hop, on économise deux instructions "load".

      Ensuite, tu as le compilateur con qui compile tout ça dans l'ordre, et qui est obligé d'attendre que x = y + z; soit fini pour commencer t = x + w; et celui qui a remarqué qu'en executant à la place

      x = y + z;
      a = b + c;
      t = x + w;

      On avait la même sémantique, mais qu'on utilisait mieux le pipelining du processeur. Et oui, le même ensemble d'instructions assembleurs ne s'executent pas à la même vitesse selon l'ordre dans lequel elles passent. Fait du pas à pas avec gdb dans du code compilé avec "-g -O3", tu verras que le curseur revient parfois en arrière.


      Maintenant, tu as raison sur le fait qu'il y a bien d'autre choses à benchmarker. (les parcours de tableaux par exemple, c'est un cas d'école en matière de compilateur optimiseur).

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  . Évalué à 3.

        Ben ça sert à quoi alors de compiler avec -O3 ?

        A demander à ton compilo de compiler correctement... tu mets en production du code non optimisé toi? tu as l'impression que les compilé (réellement utilisé) se différencie beaucoup de part leur optimisation? Combien de % tu gagnes sous le profiler en passant d'un compilo à l'autre pour l'ensemble d'une application?

        Si tu veux tester des compilos (et non plus des langages), tu pourrais en cherchant un fouillant un peu plus les optimisations, faire ce genre de test... mais regarde les sources des différents tests, rien de tout cela, attribution des registres assez triviale, on teste le temps du add, sub, div et mul...

        Ensuite, il y'aurait également une discussion possible: doit on tester le source le plus lisible? le même source pour chaque compilo? (par exemple .NET a tendance à moins virer les boucles "inutiles" que java, certains ont étés jusqu'à pondre des bench du genre "java 100.000 fois plus rapide que .NET" en partant de ce genre de truc).

        En bref, je maintiens: "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,..."

        D'ailleurs regarde les résultat, en dehors de certaines abhérations, on a globalement la même, les abérations, sont amha du a un manque de connaissance du langage (activé ou pas le check des bornes, quelle précision, etc...). Et je maintiens, peu importe le langage (compilé), une addition prendra toujours le même temps, puisqu'elle se retrouvera toujours d'une façon ou d'une autre transformer en "add A, B" (au moins sur intel et sauf cas spécifique permettant une optimisation plus poussée).

        Enfin... de toute façon, comme dirait l'autre, ocaml vaincra ;)

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  (site web personnel) . Évalué à 3.

          >> Ben ça sert à quoi alors de compiler avec -O3 ?

          > A demander à ton compilo de compiler correctement...

          Ben c'est toi, deux commentaire plus haut, qui me disait que pour des opérations arithmétiques, le temps d'execution devait toujours être le même.

          Si tu as une option pour optimiser, c'est bien qu'il est possible de faire des choses différentes pendant la compilation.

          • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

            Posté par  . Évalué à 2.

            Si tu as une option pour optimiser, c'est bien qu'il est possible de faire des choses différentes pendant la compilation.

            Dans des cas complexes, oui... (quoi que c'est pas trivial à trouver, et tu auras des cas favorable à l'un puis à l'autre, je pense) mais ici, regarde le code!

            L'optimisation ça joue essentiellement sur l'inline, le folding, et quelques trucs plus tordu. Les algos d'allocation de registre sont au point depuis un moment, un add reste un add...

            Pourquoi les compilos n'optimisent pas "toujours"? Simplement pour le debugging...

            En fait ce que je tente d'exprimer, c'est que l'algo utilisé est tellement CPU-bound que ça devient un test de cpu et plus un test de langage.

            Et en fait, ça va même plus loin: tester un langage n'a pas beaucoup de sens, c'est tester tout ce qui va avec, par exemple jouer à C contre C# n'a pas de sens si tu te limites à faire quelques opérations arithmétique, dans ce cas, le simple fait de jouer avec des string permettra de faire ressortir quelques avantages de l'un et de l'autre.

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  (site web personnel) . Évalué à 5.

      gcc sous cygwin est vraiment tres tres lent. Il dit qu'il a compile avec les lib windows donc il se pourrait que ce soit plus rapide que ce que je connais. Mais quand meme. Il faut compter un rapport 10 entre gcc et visual sous windows.

      Pour gcc/windows vs gcc/unix, je dirai qu'il y a un rapport de 5.

      Sinon, c'est connu que gcc est loin d'etre une foudre de guerre. Pas facile de supporter 350 architecture et d'avoir une equipe de dev reduite.

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  . É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  (site web personnel) . Évalué à -1.

      Seulement le problème de la complexité n'intervient que dans les algorithmes qui font du calcul... Il faut aussi voir que beaucoup d'applications ne font jamais de math et qu'en l'occurence les différences de rapidité deviennent non négligeable (réactivité de l'interface, etc). Tout est une question de compromis.

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  . Évalué à 2.

      Je ne suis que pertiellement d'accord avec toi. OCAML est un très joli langage mais le coup de la complexité, c'est quand même un peu pipo.
      La complexité, je connais bien. C'est mon fond de commerce pour pouvoir faire des trucs bien théorique sur des graphes. Si on me demande à quoi ça sert, je répond que sur de grosses classes de graphe, je sais résoudre des problèmes NP-complets en temps linéaire.

      Oui mesdames et messieurs, vous avec bien vu, en temps LINÉAIRE!!!

      Sauf que bien évidemment dans la constante, il se cache un 2^k qui rend tout ce que je dis bidon mais je m'en fout, moi, je suis un théoricien.

      Pourquoi tout le monde utilise-t-il quicksort alors qu'il n'est pas optimal? Alors que heapsort est optimal et est un tri en place? Tout simplement parce que dans la vraie vie, ben quicksort est plus rapide.

      Dans le même genre le problème de savoir si une solution est optimale pour un programme linéaire entier est NP complet. Pourtant la prog linéaire, dans la vraie vie...

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  (site web personnel) . Évalué à 7.

        Tu parles de complexité dans le pire cas, et là, tu as raison.

        Maintenant, c'est un fait que le fait de programmer dans un langage de haut niveau permet souvent d'écrire des algos avec une meilleure complexité moyenne.

        C'est ce que j'explique toujours aux gens qui pensent que l'assembleur est le meilleur langage pour faire du code efficace : Avec une main d'oeuvre réduite, c'est souvent faux. Si tu me donnes 5 minutes pour faire un tri de tableau, si je le fais en C, je vais faire un quicksort (n.log(n) en moyenne, n^2 dans le pire cas), en assembleur, je vais faire un tri par insertion (n^2), et en C++, je vais utiliser la STL qui a déjà tout fait pour moi (Un mélange de quicksort, de tri fusion et de tri par insertion si mes souvenirs sont bons. l.log(n) dans tous les cas.). D'ailleurs, en C++, il me reste 4minutes30 pour aller prendre un café ;-)

        Je ne parle même pas de table de hash, de pattern-matching d'expressions régulières ou autres algos un minimum compliqués !

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  (site web personnel) . Évalué à 1.

        > je sais résoudre des problèmes NP-complets en temps linéaire
        mmm mmm mmm
        En fait si tu sais resoudre en temps lineaire (donc polynomial) ne serait-ce qu'un seul des milliers de problemes NP complets qui existent, tu devrais communiquer tes resultats et/ou ta methode, car cela veut dire qu'il existe des algorithmes en temps polynomial pour resoudre *tous* les problemes NP-complets...

        Il ne resterait plus qu'a les chercher, ce qui ne sera pas immediat, mais savoir que P=NP serait une petite revolution 8-)

        Par exemple il faudrait mettre au placard tous les algos actuels de chiffrement, ce qui ne serait pas tres pratique!

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  (site web personnel) . Évalué à 2.

          >> je sais résoudre des problèmes NP-complets en temps linéaire
          > mmm mmm mmm
          > En fait si tu sais resoudre en temps lineaire (donc polynomial) ne serait-ce qu'un seul des
          > milliers de problemes NP complets qui existent, tu devrais communiquer tes resultats et/ou
          > ta methode,

          Tu aurais pu citer toute la phrase :

          > sur de grosses classes de graphe, je sais résoudre des problèmes NP-complets en temps linéaire.

          Ben oui, un problème NP complet est un problème pour lequel on ne connais pas d'algo polynomial dans le pire cas, mais on peu toujours trouver de meilleurs algos dans la plupart des cas si on limite à un sous-ensemble des entrées possibles.

        • [^] # NP vs linéaire

          Posté par  . Évalué à 2.

          Oui, mais parfois le problème est exponentiel dans l'absolu, mais linéaire dans la pratique (ie: dans la quasi-majorité des cas) ou à une petite approximation près.

          Dans le premier cas, on peut utiliser un algorithme aléatoire pour gommer l'apparition du pire des cas. (Ce ne sera par exemple pas exploitable par un pirate voulant tenter un DOS.)

          Exemple de problème pour le deuxième cas :
          * soient deux disques durs de capacité N chacun. On a tout un tas de programmes de taille Ni (Ni = 75 To pour i=emacs par exemple).
          Combient peut-on stocker au maximum de programmes sur ses disques ?

          On laisse comme exercice au lecteur de démontrer que :
          1) ce problème est NP-dur
          2) il y a une solution triviale qui se calcule en temps linéaire et qui donne le bon résultat à 1 près.

          • [^] # Re: NP vs linéaire

            Posté par  . Évalué à 3.

            Mais pourquoi est-on obligés de faire des maths pour faire de l'info ? Halala, c'est horrible...

            • [^] # Re: NP vs linéaire

              Posté par  . Évalué à 2.

              > Mais pourquoi est-on obligés de faire des maths pour faire de l'info ? Halala, c'est horrible...

              Parce qu'il manque des noms pour désigner les pratiques de l'info.

              La def de base, est du genrer:« quelqu'un dont le boulot est centré sur les ordinateurs est un informaticien ».

              Résultat, un analyste programmeur est un informaticien, un administrateur système est un informaticien, un webmaster est un informaticien, un chercheur en informatique est un informaticien...

              Sauf que tous ces gens ne font pas le même boulot. Je rentre dans la troisième catégorie (doctorant en informatique). Pourtant, toutes mes publications sont dans des revues et des confs de math. Je n'utilise d'ordinateur pour mon boulot que pour le mail et rédiger mes papiers.

              • [^] # Re: NP vs linéaire

                Posté par  . Évalué à 2.

                Pour info, parmi les mathématiciens, il y a:
                * ceux qui font de l'analyse numérique;
                * ceux qui font des probabilités;
                * ceux qui font de l'algèbre;
                * ceux qui font de la géométrie;
                * ceux qui font de la théorie des nombres;
                * ceux qui font de la logique;

                Et même dans cette liste, il serait dangereux de confondre géomètres différentiels et géomètres algébristes, qui n'ont ni le même langage, ni les mêmes outils!

                Tout ça pour dire que dans une grande spécialité, il y a toujours des choses très différentes, et qu'il ne faut pas s'en émouvoir.

                Snark

                PS: ma spécialité c'est la théorie des nombres; les méthodes que j'ai utilisées dans ma thèse sont plutôt analytiques, mais à la base je suis plutôt méchamment algébriste. :-)

                • [^] # Re: NP vs linéaire

                  Posté par  . Évalué à 2.

                  Je suis tout à fait d'accord cependant, si tu dis que tu es mathématicien, les gens disent:« Ahhhhhh..... » ou ils te parlent de leur prof de math de 4ème qui était un vrai con.
                  Ceux qui n'ont pas cette réaction ont de très fortes chances de savoir qu'il y a matheux et matheux.

                  Alors que quand tu dis que tu es informaticien, les gens pensent savoir ce que ça veut dire alors que ce n'est pas forcément le cas.

              • [^] # Re: NP vs linéaire

                Posté par  . Évalué à 2.

                Résultat, un analyste programmeur est un informaticien, un administrateur système est un informaticien, un webmaster est un informaticien, un chercheur en informatique est un informaticien...

                [...]

                Je rentre dans la troisième catégorie (doctorant en informatique).

                Il me semble plutôt que la troisième catégorie, c'est les webmasters ;)

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  . Évalué à 2.

          Bon, je vais citer mes sources.

          Fais une recherche sur « treewidth » (c'est un truc définit par N. Robertson et P.D. Seymour) puis sur « Bruno Courcelle » et « monadic second-order logic ».

          En gros, on peut définir à quel point un graphe ressemble à un arbre. Un graphe complet, ça ne ressemble pas du tout à un arbre mais un truc plus « filandreux » si. Pour mesurer ça, on définit la treewidth d'un graphe. Tout graphe à une treewidth donnée. Savoir si un graphe G est de treewidth k est NP-complet.

          Il y a des théorèmes qui disent que tout problème sur des graphes qui s'exprime en logique monadique du second ordre est linéaire sur une classe de graphe de treewidth bornée. En gros, la complexité est de l'ordre de O(n*2^k). Alors évidemment, ça fait joli mais il existe évidemment des graphes de taille n ayant une treewidth de l'ordre de n ce qui réduit beaucoup l'interet de ce genre d'approche.

          Et pour revenir sur tes problèmes de chiffrement, rien que pour le problème de factorisation, il faut faire très gaffe. Il y a des algos qui marchent très bien quand il y a des facteurs petits, il y en a d'autre qui marchent très bien quand les facteurs sont de taille comparable... Bref, pour choisir une clef RSA qui ne se casse pas très vite, c'est pas évident du tout.

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  (site web personnel) . É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.

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  (site web personnel) . Évalué à -3.

      Par contre ce test a été effectué sous Windows. Il aurait été intéressant de comparer les perfs sous Nux aussi, sans rentrer dans le troll de comparer les perfs entre Windows et Nux, mais juste pour voir si l'ordre des langages change d'une plateforme à l'autre.

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  (site web personnel) . Évalué à -1.

        Pour moi il y a également une chose très intéressante à tirer de ce bench : si l'on compare tous les langages .NET (VB, C# et J#), on a quasiment des perfs identiques sur tous les tests. Normal puisque tous ces langages utilise le même code itnermédiaire CIL dessous. Mais comme quoi c'est l'implémetation qui fait la différence et pas du tout le "langage" en soit.

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  (site web personnel) . Évalué à -6.

          Tout à fait d'accord avec toi. D'ailleur il faudrait que tu penses à arrêter de te répondre à toi-même parcque là franchement tu vas te faire moinsser à force de flooder comme ça.

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  (site web personnel) . Évalué à -10.

          Franchement je vois pas ce que j'ai dit de mal qui justifie ce moissage arbitraire. Vraiment y'a des andouilles ici, qui en plus ne prenne pas le temps d'exprimer leurs idées (peut être ony-ils peurent de se faire moinsser pour leurs idées ?)
          Par contre ce post vous pouvez le moinsser :)

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  (site web personnel) . Évalué à 3.

          > Mais comme quoi c'est l'implémetation qui fait la différence et pas du tout le "langage" en soit.

          C'est surtout l'implémentation, mais le langage te dit par exemple

          * Si c'est compilé ou interprêté (Les langages qui permettent de créer et d'executer dynamiquement du code peuvent difficilement être compilés)

          * Si tu travailles en sémantique de valeur ou de référence (si tu manipule des objets ou des des pointeurs)

          * Quelle est la gestion de la mémoire (garbage collection ou libération manuelle)

          * Si tu fais des tests de débordement ou pas

          * Si la résolution de la surcharge de fonction est statique ou dynamique (virtual ou pas en C++)

          ...

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  (site web personnel) . Évalué à -5.

      Je tiens à préciser que j'ai fait ce benchmark sur leurs exemples et que donc ma conclusion n'est applicable que dans ce contexte. (pour éviter le troll)

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  (site web personnel) . É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(...)

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  . Évalué à 3.

      Tout à fait, allez voir cette url, même si les résultats ne sont plus tous frais!

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

      Le test présenté dans cette news n'est vraiment pas sérieux,
      la moitié des languages présentés ne sont pas portables et
      spécifiques à windows...
      De plus Objective Caml n'est même pas présent dans la liste alors qu'il sortait grand vainqueur du test de bagley.org (PHP sortait grand perdant si je me souviens bien)!

      Amusez vous avec l'url précédante: beaucoup de combinaisons différentes des poids des résultats font sortir ocaml dans les premiers!
      C'est hallucinant!

      Tester visual basique me fait doucement rire: l'interpréteur VB plante avec
      des choses comme un IF condition THEN action1 ELSE action2 (avec la vrai syntaxe VB et des vrais instructions) sur une seule ligne, sans retours chariots:
      il n'est même pas capable de parser correctement!!!

      Poster les résultats d'un tel bench n'était pas une très bonne idée.

      :O(

  • # Oubli ?

    Posté par  (site web personnel) . É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: Oubli ?

      Posté par  (site web personnel) . Évalué à -5. Dernière modification le 04 décembre 2021 à 20:15.

      Je comprends pas … tu parles de www.templeet.org ?

      Si c'est ça, ca n'a rien a voir.

      http://about.me/straumat

      • [^] # Re: Oubli ?

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 04 décembre 2021 à 20:15.

        _ Je comprends pas … tu parles de www.templeet.org ?

        Si c'est ça, ca n'a rien a voir. _

        ;-) parfois, ca vaut le coup de voir les messages moinssés (comme le miens par exemple: p)

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  (site web personnel) . É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  . É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: Garçon, y'a du code moisi dans mon verre de pipotron !

      Posté par  . Évalué à 2.

      Euh, je suis pas un programmeur python, mais Matlab.
      Il me semble que il serait plus juste de creer un vecteur
      x=range(1,max)
      et ensuite d'appeler les fonctions avec ce vecteur comme argument.

      Si quelqu'un venait me voir en disant: matlab, c'est pas rapide et que son code était bourré de boucles for imbriquées, je lui mettrait 2 baffes (figurées les baffes). Pareil si il me codait ce bench de cette manière.

      Les langagesde type semi-interprétés ne doivent pas s'utiliser comme du C transcrit ligne à ligne. C'est idiot (et je suis gentil).

      Qu'en pensent les spécialistes de Python, c'est plus rapide avec un array?

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  . Évalué à 10.

    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  . Évalué à 3.

      On est tous d'accord là dessus !

      On part du principe que l'on conait les avantages des langages.

      Ce qu'on veut, c'est évaluer les performances pures des langages/compilo pour pouvoir mieux choisir (ce que tu disais). Sinon, moi, c'est évident j'ecris tout en python ! D'où l'importance de savoir ce que je vais vraiment perdre à écrire mon code en python ou si je dois faire du C voir carrement de l'assembleur.

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  . Évalué à 3.

      D'accord avec ton analyse, mais il y a d'autre langage qu'eiffel qui vérifie les concordances spec code. il existe La méthode B ou langage B dont la specificité est d'avoir le même langage pour les "spec et le code".

    • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

      Posté par  . Évalué à 3.

      Oui, en tant que codeur. En tant qu'utilisateur, la maintenabilité ou le temps de dev je m'en tamponne le coquillard.
      Et il serait bon de ne pas trop oublier les utilisateurs, quand meme, quand on choisi un langage.

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  (site web personnel) . Évalué à 2.

        > En tant qu'utilisateur, la maintenabilité ou le temps de dev je m'en tamponne le coquillard.

        Ah bon, pas moi. Moi, je préfère avoir un logiciel un peu lent, gratos, et tout de suite, plutôt que d'attendre 20 ans que le portage en assembleur soit terminé, et de devoir le payer une fortune pour payer tous les devs qui ont bossé dessus.

        Sur la plupart des projets, tu as une quantité de main d'oeuvre limitée, et la question, c'est connaissant cette quantité de main d'oeuvre, que vas tu pouvoir faire.

        Il y a des cas ou la quantité de main d'oeuvre est grande et la fonctionalité du logiciel limitée (par exemple Apache : Un serveur web n'est pas un truc complexe en soi, c'est de faire un serveur web rapide qui est dur), et alors, on prend un langage de bas niveau.

        Il y a des cas ou la fonctionalité est plus complexe et la main d'oeuvre insuffisante pour faire un truc à la fois évolué et rapide. Dans ces cas là, tu programmes avec un langage de haut niveau et tu atteint tes objectifs rapidement.

        • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

          Posté par  . Évalué à 0.

          Le célèbre mythe du mois homme serait donc lui meme un mythe ?

          non je ne crois pas

          :-)

          • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

            Posté par  (site web personnel) . Évalué à 1.

            Puisque tu as l'air d'avoir une théorie là dessus, alors de quoi dépends la "qualité" d'un logiciel du point de vue utilisateur ? Est-ce totalement décorrélé de la quantité de main d'oeuvre ?? Et totalement décorrélé du langage utilisé ???

            Bah, alors t'as qu'à ré-écrire Mozilla en assembleur, tout seul et en 5 minutes, ça m'intéresse.

            • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

              Posté par  . Évalué à 1.

              De quoi dépend la qualité d'un logiciel de mon point de vue d'utilisateur :

              1) Ca prend pas 10Mo sur le disque
              2) Quand je le lance, ca démarre de suite
              3) Ca fait une seule chose mais ca le fait bien
              4) C'est gratuit ou pas cher et dans ce cas je peut tester avant de payer
              5) Je comprend comment on s'en sert sans lire de doc

              Voilà, évidement subjectif, et dans un ordre aléatoire.

              Maintenant, c'est certainement pas décorélé avec la quantité de main d'oeuvre. En effet, l'expérience m'a montré qu'en général plus un logiciel était concu par une armada de développeurs (en général commandé par une armada de commerciaux), plus il avait tendance à ne satisfaire aucun des critères précédent.

              Quand à ré-écrire mozilla en assembleur, le _seul_ inconvénient que j'y voit c'est que ca ne tournerait alors que sur une seule architecture.
              Je ne comprendrai jamais pourquoi certaines personnes font une fixette comme ca sur l'assembleur... Tu peut me renseigner ??

              • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

                Posté par  (site web personnel) . Évalué à 1.

                > le _seul_ inconvénient que j'y voit c'est que ca ne tournerait alors que sur une
                > seule architecture.

                Non, il suffirait de le réécrire autant de fois qu'il le faut. Si tu veux porter Mozilla sur 10 architectures différentes, ça aurait l'avantage de diviser la taille de l'équipe pour chaque architecture par 10, donc, selon toi, d'augmenter ses chances de satisfaire tes critères. La portabilité aussi est un moyen d'optimiser la main d'oeuvre, pas une fin en soi.

                Maintenant vas-y, si c'est une bonne chose selon toi de réécrire Mozilla en assembleur, et si tu penses qu'une grosse équipe n'est pas une bonne idée, lances-toi, on n'attends que ça.

              • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

                Posté par  . Évalué à 1.

                Quand à ré-écrire mozilla en assembleur, le _seul_ inconvénient que j'y voit c'est que ca ne tournerait alors que sur une seule architecture.

                1) Developpement plus long
                2) Nombre de gens pouvant participer au developpement tres limite de par le manque de connaissance de l'assembleur, manque d'interet pour un truc aussi inutile et long a faire
                3) Maintenance hyper difficile de par la quantite de code et sa complexite
                4) Nombre de bugs plus eleve(cf. 3)
                5) Rend l'utilisation de Mozilla par d'autre softs plus difficile

                Voila, j'ai deja 5 raisons de ne pas l'ecrire en assembleur, sans compter celle sur la non-portabilite

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  . Évalué à 2.

        En tant qu'utilisateur, un programme qui n'a aucune chance de survie à moyen terme, ça ne m'intéresse pas trop... Donc je suis assez intéressé par les programmes dont le code se lit bien, et pour lesquels de nouveaux mainteneurs ont des chances d'apparaître.

        Snark

      • [^] # Re: Comparaison de neuf langages sur un micro-benchmark

        Posté par  . Évalué à 1.

        Si c'était si simple... les deux sont liés, si le dev gagne du temps, il peut ajouter des fonctionnalités, s'il ajoute des fonctionnalités c'est pour toi...

        Il faut également penser au problème de sécurité: du C mal codé permet facilement d'avoir des failles, du java mal codé limite déjà cela (difficile de jouer sur les overflow par exemple). (note: Cela ne veut pas dire que java est "mieux" que C... mais que le choix du langage a un effet sur l'utilisateur).

        Aussi dans le contexte du logiciel libre, les choix des développeurs sont capitaux: que dire d'un projet GPL dont les sources sont illisible et inexploitable? La licence est GPL... mais pourtant difficile de profiter de tous les effets bénéfiques pour l'utilsateur de cette licence.

        De plus, un développeur ne choisit pas qu'un langage, mais tout ce qui va avec.... comme par exemple le toolkit graphique, et à nouveau ça a une répercussion sur ... l'utilisateur.

        En bref, tu peux choisir d'ignorer le langage, la plate forme et les libs et outils utilisés, mais ça a pourtant une influence sur toi. Je suis d'accord avec le fait qu'il ne faut pas "prendre en otage" l'utilisateur avec la nouvelle technologie XYZ mais l'utilisateur fait bien partie de l'équation, et le logiciel libre te permet de t'exprimer la dessus et d'être potentiellement mieux écouté...

  • # Re: Comparaison de neuf langages sur un micro-benchmark

    Posté par  . É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 ...

Suivre le flux des commentaires

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