Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Expert éminent sénior
    Le langage Go se mesure à C++, Java et Scala : une nouvelle étude comparative des performances
    Le langage Go se mesure à C++, Java et Scala
    Une nouvelle étude comparative des performances, menée par un ingénieur de Google




    L'ingénieur de Google Robert Hundt vient de publier un rapport comparatif entre Java, Scala, C++ et Go, le langage de programmation maison de Google.
    Ce rapport se base sur l'analyse de différents facteurs suite à l'implémentation compacte du même algorithme dans les quatre langages.

    Sans surprise, le langage C++ est le plus économe en mémoire vive et celui qui offre la Runtime la plus rapide.
    Le résultat de ce benchmark dévoile en revanche que c'est le langage qui nécessite le plus « d'effort d'optimisation », des manipulations parmi lesquelles certaines sont « à un niveau de sophistication hors de la portée du développeur moyen », affirme Robert Hundt.

    La mise en oeuvre du code de l'implémentation Java de l'algorithme a été la plus facile d'après le rapport. L'analyse des performances du langage est en revanche la plus complexe, notamment autour des effets du ramasse-miette (Garbage Collector), très difficile à optimiser.

    Le langage Scala, qui tourne sur la JVM, et compile tout comme Java en byte-code, partage la même complexité d'analyse et d'optimisation des performances, mais sa notation concise et les puissantes fonctionnalités du langage offrent la meilleure optimisation de la complexité du code.

    Quant à Go, Robert Hundt estime qu'il offre des fonctionnalités de langage intéressantes qui rendent possible l'écriture d'expressions concises et standardisées.
    Le rapport rappelle que les compilateurs pour ce langage « restent immatures, ce qui se traduit à la fois sur les performances et la taille de l'exécutable »

    Sur ce dernier point, les résultats de l'implémentation sont à la traine pour Go qui produit un exécutable de 1.2 Mo contre 13 Ko pour Java et 41 Ko pour C++.
    C++ et Go compilent en code-machine, contrairement à Java et Scala. À ce propos, Go compile nettement plus vite que ses trois rivaux.

    Le langage Go a été conçu depuis sa création il y a un an et demi comme un langage de programmation concurrentielle tout en conservant les performances d'un langage de bas niveau comme C++ et étant proche en apparence des langages dynamiques type Python.

    Cette étude comparative de Google s'est déroulée en deux phases afin d'offrir l’équivalence la plus objective qui soit.
    La première phase n'a utilisé que les fonctionnalités idiomatiques des langages (classes, boucles, schéma d'allocation de la mémoire...), sans utiliser des outils spécifiques destinés à maximiser les performances.

    Après la publication des résultats de cette phase, divers ingénieurs de Google se sont attelés à optimiser par tous les moyens disponibles l'implémentation de chaque langage.

    La comparaison des résultats des deux phases est d'après l'étude « révélatrice de la difficulté typique d'optimisation dans les langages respectifs ».



    Le rapport est consultable via ce lien (PDF, 330 Ko, 10 pages)


    Et vous ?

    Que pensez-vous des résultats de cette étude ?
    Et du langage Go et ses perspectives d'avenir ?

  2. #2
    Responsable Qt & Livres

    Intéressant... surtout de la part de Google, d'où émerge Go, donc où on devrait trouver des gens qui ont travaillé dessus, le connaissant bien, y compris les compilateurs.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  3. #3
    Modérateur

    Citation Envoyé par Idelways Voir le message
    [B]...
    Sur ce dernier point, les résultats de l'implémentation sont à la traine pour Go qui produit un exécutable de 1.2 Mo contre 13 Ko pour Java et 41 Ko pour C++.
    C++ et Go compilent en code-machine, contrairement à Java et Scala. À ce propos, Go compile nettement plus vite que ses trois rivaux.

    ...
    Il est probable que les différences diminuent que ce soit au niveau de la taille de l'exécutable (qui va diminuer) qu'au niveau du temps de compilation (qui va augmenter).
    L'optimisation a un coût.

    Que pensez-vous des résultats de cette étude ?
    c'est une analyse utile qui apporte des chiffres. Mais les résultats étaient prévisibles ou connus avant.

    Et du langage Go et ses perspectives d'avenir ?
    J'avoue ne pas connaître la syntaxe, ni les libraires disponibles dans ce langage. Il est peut-être trop tôt pour savoir si ce langage a un avenir.

    K
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  4. #4
    Membre expérimenté
    Citation Envoyé par kolodz
    Il est probable que les différences diminuent que ce soit au niveau de la taille de l'exécutable (qui va diminuer) qu'au niveau du temps de compilation (qui va augmenter).
    L'optimisation a un coût.
    Oui et non, la taille des binaires de base de Go est lié au fait que c'est un langage hautement réflectif et à garbage collector sans VM contrairement à C++ ou à Java. Ces fonctionnalités doivent donc être directement ajoutées au binaire, et ça gonfle la taille de "base" de l'executable.

    Ceci dit, pour des programmes de grosse taille, il y a fort à parier que l'écart se réduise fortement.
    It's not a bug, it's a feature

  5. #5
    Membre extrêmement actif
    Que pensez-vous des résultats de cette étude ?
    Que pour l'instant ce langage ne présente que peu d’intérêt.

    Et du langage Go et ses perspectives d'avenir ?
    Je me demande quel-est l'objectif à long terme.
    Ce ne serait jamais aussi performant que le C++.
    Ni aussi facile à programmer que du JAVA.
    Ils veulent juste rendre possible l'écriture d'expressions concises et standardisées et accélérer le temps de compilation ?
    Keith Flint 1969 - 2019

  6. #6
    Rédacteur/Modérateur

    Citation Envoyé par Idelways Voir le message
    Quant à Go, Robert Hundt estime qu'il offre des fonctionnalités de langage intéressantes qui rendent possible l'écriture d'expressions concises et standardisées.
    Le rapport rappel que les compilateurs pour ce langage « restent immatures, ce qui se traduit à la fois sur les performances et la taille de l'exécutable »

    Sur ce dernier point, les résultats de l'implémentation sont à la traine pour Go qui produit un exécutable de 1.2 Mo contre 13 Ko pour Java et 41 Ko pour C++.
    C++ et Go compilent en code-machine, contrairement à Java et Scala. À ce propos, Go compile nettement plus vite que ses trois rivaux.

    Le langage Go a été conçu depuis sa création il y a un an et demi comme un langage de programmation concurrentielle tout en conservant les performances d'un langage de bas niveau comme C++ et étant proche en apparence des langages dynamiques type Python.

    A la vue de tels résultats, on ne peut que se demander ce qui a réellement poussé Google à sortir son langage Go... il compile vite, mais mal aussi bien en pour optimiser la taille que la vitesse. Il n'est pas si innovant : la plupart de ces concepts sont déjà présents dans d'autres langages de programmation, et il existe pas mal d'études sur leurs optimisations.

    Il est probable que tous ces défauts seront vite corrigés, d'autant plus que le fait que Go ne soit pas si innovant implique que de nombreux back-ends de compilation existants et performants pourront être adaptés... la seule question étant : pourquoi ne pas l'avoir déjà fait ? la version actuelle de Go ne serait-elle qu'un PoC ?
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  7. #7
    Futur Membre du Club
    Citation Envoyé par gorgonite Voir le message
    A la vue de tels résultats, on ne peut que se demander ce qui a réellement poussé Google à sortir son langage Go... il compile vite, mais mal aussi bien en pour optimiser la taille que la vitesse. Il n'est pas si innovant : la plupart de ces concepts sont déjà présents dans d'autres langages de programmation, et il existe pas mal d'études sur leurs optimisations.
    Pour la qualite du code genere, l'implementation officielle produit du code simple sans optimisations avancees. L'idee est d'avoir quelquechose qui marche d'abord. Pour la taille des binaires c'est tout simplement lie au fait que les createurs du language sont contre les "shared object" et que donc chaque binaire inclu la runtime et bibliotheque standard.
    Ces deux problemes sont regles par le second compilateur Go: gccgo, qui est plus lent pour compiler, mais qui produit du code plus optimise et gere les .so

    Citation Envoyé par gorgonite Voir le message
    la version actuelle de Go ne serait-elle qu'un PoC ?
    Oui et non La version actuelle de Go est plus qu'un PoC mais il a ete decide d'implementer certaines fonctionalite rapidement pour avoir un language fonctionnel et developper l'ecosysteme. On pensera plus particulierement au garbage collector qui est tres simple (et il marche!) mais peut etre reimplemente pour diminuer les pauses liee a un cycle de collection.

  8. #8
    Membre averti
    a mon avis Go sera un flop , si les developpeurs veulent un control totale sur la machine et de la puissance il 'y a C/ASM ou C++/ASM si il veulent de la portabilite il y'a JAVA (Mono ayant des problemes ces temps si je me tairais a propos de C# ) , si il veulent une productivite enorme il y'a JAVA ou C# . car énormément de bibliothèques sont mature pour tous ces language et ont fait leur preuves le plus jeune language etant C# et a 13ans ( le developpement de .NET a ete annonce en 1998 ) contre 39 pour le C qui est sorti en 1972 . donc Go aussi rapide soit t'il il faut les outils qui vont avec en plus de sa ce n'est pas du jour au lendemain qu'on va laisser tomber C++ / JAVA qui ont des racines bien enraciné et tous une histoire et des habitudes .

  9. #9
    Membre extrêmement actif
    Effectivement je vois mal le C ou le C++ disparaître un jour.
    Mais bon ça finira probablement par arriver, même avec les mises à jour de ces langages.

    Par contre il ne faut pas ne pas essayer de créer de nouveaux langages.
    Si l'équipe qui à créer le Java s'était dit "il y a déjà le C un nouveau langage n'a pas sa place" on aurait loupé quelque chose.

    Peut être que dans 37 ans Go ce sera la langage le plus performant, léger, optimiser, portable.
    Keith Flint 1969 - 2019

  10. #10
    Nouveau Candidat au Club
    Techniquement je ne voit pas l’intérêt de ce langage, Go (home)...

  11. #11
    Membre éprouvé
    Citation Envoyé par gorgonite Voir le message
    Il est probable que tous ces défauts seront vite corrigés, d'autant plus que le fait que Go ne soit pas si innovant implique que de nombreux back-ends de compilation existants et performants pourront être adaptés... la seule question étant : pourquoi ne pas l'avoir déjà fait ? la version actuelle de Go ne serait-elle qu'un PoC ?
    J'avoue m'être posé la même question il y a quelques mois quand je m'étais penché sur ce langage. Le but est donc théoriquement d'écrire facilement du code parallèle (multi-coeur ou réparti). Et dans le domaine, comparé à du Scala ou du JoCaml, c'est le niveau zéro de l'idée qu'aurait eu un stagiaire à la pose déjeuner qu'il aurait griffoné sur une serviette en papier.

    Ensuite c'est un compilo théoriquement "from scratch", et ils ont écrit ça... en C. Dans la catégorie "j'aime me faire mal, parce que c'est ça qui est bon", ça se pose là quand même. J'ai d'ailleurs tenté de lire le code de l'allocateur de registre, c'est bourré de goto. Un vrai !@# de bonheur.

    Bref, c'est un langage sans intéret, qui "compile vite" mais produit un code merdique, et qui en plus semble avoir fait tous les choix possible et imaginable pour avoir le processus de développement le plus lent possible. Ca n'ira nul part.

  12. #12
    Rédacteur/Modérateur

    Citation Envoyé par kimelto Voir le message
    Pour la qualite du code genere, l'implementation officielle produit du code simple sans optimisations avancees. L'idee est d'avoir quelquechose qui marche d'abord.
    J'entends bien... tout le monde fait cela, mais vu la taille de Google, pourquoi ne pas avoir fait "cela" + un back-end sur un outil standard et fortement optimisant (comme déjà dit rien de si nouveau dans Go, donc c'était possible)
    Là on se retrouve encore avec un langage jouet... ce qui n'est pas digne de Google (mais plus compréhensible de la part d'un labo de recherche )

    Citation Envoyé par kimelto Voir le message

    Pour la taille des binaires c'est tout simplement lie au fait que les createurs du language sont contre les "shared object" et que donc chaque binaire inclu la runtime et bibliotheque standard.
    Chacun a droit d'avoir ses opinions, il est clair qu'il est plus simple d'avoir une libC qu'une libGo disponible par défaut sur une plate-forme...
    Mais là encore, est-ce que ça fait "pro" ? surtout quand on voit ce qu'il y a obligatoirement dans ce surcoût (là où un éditeur de lien sophistiquée aurait pu réduire la taille de ce qui est importé depuis la libC pour les binaires statiques par exemple)


    Citation Envoyé par kimelto Voir le message

    Ces deux problemes sont regles par le second compilateur Go: gccgo, qui est plus lent pour compiler, mais qui produit du code plus optimise et gere les .so
    et pourquoi des benchs utilisant aussi ce compilateur n'ont pas été fournis ?
    même en terme d'article de recherche académique, un tel oubli est difficilement acceptable


    Citation Envoyé par TropMDR Voir le message
    Ensuite c'est un compilo théoriquement "from scratch", et ils ont écrit ça... en C. Dans la catégorie "j'aime me faire mal, parce que c'est ça qui est bon", ça se pose là quand même. J'ai d'ailleurs tenté de lire le code de l'allocateur de registre, c'est bourré de goto. Un vrai !@# de bonheur.
    avoir un code C compact et performant demande parfois des sacrifices en terme de lisibilité... mais une doc technique est alors indispensable (ou alors des macros bien pensées pour redonner un peu de lisibilité justement)

    des goto partout sur des architectures sans prédiction de cache exotiques, ça peut parfois être intéressant (je me souviens d'un interprète de bytecode Java version threaded-code )

    Citation Envoyé par TropMDR Voir le message
    Bref, c'est un langage sans intéret, qui "compile vite" mais produit un code merdique, et qui en plus semble avoir fait tous les choix possible et imaginable pour avoir le processus de développement le plus lent possible. Ca n'ira nul part.
    c'est un peu l'idée que je partage (avec un peu plus de diplomatie )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  13. #13
    Membre confirmé
    Je ne peux m'empêcher de penser à OpenCL et CUDA pour les calculs parallèles de hautes performances.

    La différence de perf avec les CPU étant déjà d'un facteur 100 (minimum), je n'imagine même pas avec du Go ...

  14. #14
    Futur Membre du Club
    Il y a bien une niche pour Go: les gens comme moi qui n'aime pas le C++ et Java. Jusqu'a present je pouvais compter que sur le C et Python. Go se place bien entre les deux (laissant a python "que" l'avantage du nombre de bibliotheques).
    Et meme sur ce point, il est tres facile de faire des bindings de bibliotheques C en Go.

    Alors apres c'est sur que si vous adorez Java vous allez pas aimer Go. Go est en quelque sorte un anti-Java. Les developpeurs de Go aiment dire que Go est oriente Object, Java est oriente Type.

  15. #15
    Membre éprouvé
    Pour ma part, j'ai l'impression qu'on a autant besoin d'un nouveau langage de programmation que d'une nouvelle distribution Linux ...
    The greatest shortcoming of the human race is our inability to understand the exponential function. Albert A. Bartlett

    La plus grande lacune de la race humaine c'est notre incapacité à comprendre la fonction exponentielle.

  16. #16
    Rédacteur/Modérateur

    Citation Envoyé par kimelto Voir le message
    Il y a bien une niche pour Go: les gens comme moi qui n'aime pas le C++ et Java. Jusqu'a present je pouvais compter que sur le C et Python. Go se place bien entre les deux (laissant a python "que" l'avantage du nombre de bibliotheques).
    Il y avait déjà RPython...
    http://code.google.com/p/rpython/

    Citation Envoyé par kimelto Voir le message

    Alors apres c'est sur que si vous adorez Java vous allez pas aimer Go. Go est en quelque sorte un anti-Java. Les developpeurs de Go aiment dire que Go est oriente Object, Java est oriente Type.

    dire que la déclaration systématique des types rend Java verbeux, ok, mais dire que Java est "orienté-type"

    Citation Envoyé par jmnicolas Voir le message
    Pour ma part, j'ai l'impression qu'on a autant besoin d'un nouveau langage de programmation que d'une nouvelle distribution Linux ...
    on n'a jamais eu besoin d'autre chose qu'un assembleur en théorie... mais en pratique, chaque petite amélioration est une étape pour adapter la programmation à une catégorie supplémentaire (les gens qui veulent la même chose mais en version payante/gratuite/à soi , les gens qui n'aiment pas certains aspects/contraintes, etc)

    le marché des (E)-DSL pourrait d'ailleurs même en partie mettre la programmation au niveau des non-informaticiens
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  17. #17
    Membre éprouvé
    Citation Envoyé par gorgonite Voir le message
    avoir un code C compact et performant demande parfois des sacrifices en terme de lisibilité... mais une doc technique est alors indispensable (ou alors des macros bien pensées pour redonner un peu de lisibilité justement)

    des goto partout sur des architectures sans prédiction de cache exotiques, ça peut parfois être intéressant (je me souviens d'un interprète de bytecode Java version threaded-code )
    On parle d'un compilo là. La préoccupation première, c'est qu'il produise un code
    1) correct (dans le sens de "qui fait la même chose que ce qu'a écrit le programmeur)
    2) efficace
    Le fait que le compilo lui même aille vite, c'est assez secondaire. Donc je ne vois vraiment pas l'intéret d'un code moisi juste pour que "ça aille vite".

    Citation Envoyé par gorgonite Voir le message
    c'est un peu l'idée que je partage (avec un peu plus de diplomatie )
    Ouais mais toi tu es modo, t'as une obligation morale !

    Citation Envoyé par kimelto Voir le message
    Il y a bien une niche pour Go: les gens comme moi qui n'aime pas le C++ et Java. Jusqu'a present je pouvais compter que sur le C et Python.
    Euh, il n'y a vraiment que 4 langages de programmation de disponible ???

    Citation Envoyé par kimelto Voir le message
    Alors apres c'est sur que si vous adorez Java vous allez pas aimer Go. Go est en quelque sorte un anti-Java. Les developpeurs de Go aiment dire que Go est oriente Object, Java est oriente Type.
    A part la verbosité, j'aimerai bien savoir de quoi ils parlent

  18. #18
    Nouveau membre du Club
    ""Sans surprise, le langage C++ est le plus économe en mémoire vive et celui qui offre la Runtime la plus rapide.""


    c'est pour celà , je l'ai choisi

  19. #19
    Futur Membre du Club
    Citation Envoyé par TropMDR Voir le message

    Le fait que le compilo lui même aille vite, c'est assez secondaire. Donc je ne vois vraiment pas l'intéret d'un code moisi juste pour que "ça aille vite".
    De un le code est pas si moisi que ca. Il faut aussi savoir que plus le compilo fait des optimisations, plus de risque d'avoir une miscompilation est grand (gcc -O3 est deconseille). Le fait d'avoir une compilation rapide ameliore la productivite. Et la raison pour laquelle il est rapide est pas due au fait qu'il fait moins d'optimisations (en fait si, mais qu'en partie) mais au fait que si a.o a besoin de b.o (le package a utilise le package b par example) alors le code de b que a utilise est inclu dans a.o. Ca veut dire que le compilateur fait beaucoup moins de lectures, et a large echelle ca change tout.

    Citation Envoyé par TropMDR Voir le message
    A part la verbosité, j'aimerai bien savoir de quoi ils parlent
    Ils parlent surtout du fait que Java encourage heritage, et que donc le programmeur raisonne en pensant aux types.

  20. #20
    Membre expérimenté
    Citation Envoyé par kimelto Voir le message

    Ils parlent surtout du fait que Java encourage heritage, et que donc le programmeur raisonne en pensant aux types.
    L'héritage c'est quand même un principe de la POO! Et puis la généricité permet aussi une certaine souplesse...