Combien de temps peut aller aller?


39

Go est l’un des rares langages supposés fonctionner «proche du métal», c’est-à-dire qu’il est compilé, typé de manière statique et qu’il exécute le code de manière native, sans machine virtuelle. Cela devrait lui donner un avantage de vitesse par rapport à Java, C #, etc. Il semble toutefois que cela se trouve derrière Java (voir Shootout en langage de programmation ).

Je suppose que les compilateurs moins matures en sont extrêmement responsables, mais y a-t-il d'autres raisons? Existe-t-il quelque chose dans la conception de Go qui l'empêche de fonctionner plus rapidement que, par exemple, Java? J'ai une vision très peu sophistiquée des modèles d'exécution, mais il semble que, du moins en principe, il devrait pouvoir s'exécuter plus rapidement que Java, grâce à l'exécution de code natif.


3
Avec un compilateur suffisamment intelligent (et / ou une machine virtuelle, et / ou un compilateur JIT), un langage donné peut toujours aller plus vite (enfin, il y a des limitations physiques, mais c'est tout). Bien sûr, ce truisme n’aide personne tant que ce compilateur suffisamment intelligent n’est pas là. Notez cependant que Java a déjà ces implémentations suffisamment intelligentes, et elles sont incroyablement intelligentes. Une autre réalité est que l’exécution de code a au moins autant d’influence sur les performances d’exécution que l’implémentation.

1
Je comprends cela, mais je me demandais s’il était raisonnable de s’attendre à ce que la vitesse de Go atteigne / dépasse, par exemple, Java à mesure que son compilateur mûrit.
Greg Slodkowicz

17
Les langages de programmation n'ont pas de vitesse. Les implémentations linguistiques non plus. Une implémentation linguistique donnée a une vitesse pour une entrée donnée, et cette vitesse peut très grandement dépendre de l'entrée.

8
Réveille-moi… avant de partir… WHAM! . Désolé, je n'ai pas pu résister. Voici les drapeaux .. voici venir les drapeaux ..
Poster Tim

2
@delnan - Ou est-il simplement plus facile de dire "Java" que "Java Runtime Environment (version 1.6.0_25-b06) Java HotSpot (TM) 64 bits VM (version 20.0-b11) , mode mixte) ":-)
lundi

Réponses:


46

En termes de conception de langage, rien ne devrait vraiment rendre Go plus lent que Java en général. En fait, cela vous donne plus de contrôle sur la structure de la mémoire de vos structures de données. Ainsi, pour beaucoup de tâches courantes, cela devrait être un peu plus rapide. Cependant, le compilateur principal actuel, le planificateur, le ramasse-miettes, la bibliothèque regexp et bien d’autres choses ne sont pas particulièrement optimisés. Cela ne cesse de s'améliorer, mais il semble que l'accent soit mis sur l'utilité, la simplicité et la rapidité avec laquelle il est préférable de gagner des microbonds.

Dans le repère lié, Go perd gros en Java sur l’arbre binaire et le test de l’expression rationnelle. Ce sont des tests du système de gestion de la mémoire et de la bibliothèque regexp, respectivement. La gestion de la mémoire de Go pourrait être plus rapide et s'améliorera certainement avec le temps, et la bibliothèque de regexp standard actuelle est un paramètre fictif pour une mise en œuvre bien meilleure, à venir. Donc, perdre sur ces deux n'est pas surprenant, et dans un proche avenir, la marge devrait être plus étroite.

Pour le point de repère k-nucléotide, il est un peu difficile de comparer car le code Java semble utiliser un algorithme différent. Le code Go bénéficiera certainement des améliorations du compilateur, du planificateur et de l'allocateur à venir, même sous sa forme écrite, mais il faudrait que quelqu'un réécrive le code Go pour faire quelque chose de plus intelligent si nous voulons comparer plus précisément.

Java remporte le test de performance de mandelbrot car il s’agit uniquement d’arithmétique en virgule flottante et de boucles; c’est donc un excellent endroit pour que la machine virtuelle Java génère un très bon code machine et optimise les performances au moment de l’exécution. Go, en comparaison, a un compilateur assez simple qui ne lève pas, ne déroule pas et ne génère pas de code machine très serré actuellement, il n’est donc pas surprenant qu’il perde. Cependant, il convient de garder à l'esprit que le minutage Java ne compte pas le temps de démarrage de la machine virtuelle Java ni les nombreuses fois où il doit être exécuté pour que la machine virtuelle s'exécute correctement. Pour les programmes à long terme, ce n'est pas pertinent, mais cela compte dans certains cas.

Pour ce qui est des autres points de repère, Java et Go sont fondamentalement à égalité, Go consomme beaucoup moins de mémoire et, dans la plupart des cas, moins de code. Ainsi, alors que Go est plus lent que Java dans un certain nombre de ces tests, Java est assez rapide, Go se débrouille plutôt bien en comparaison et Go deviendra probablement beaucoup plus rapide dans un proche avenir.

Je suis impatient de voir gccgo (un compilateur Go utilisant le codegen gcc) arriver à maturité; Cela devrait rendre Go assez proche de C pour de nombreux types de code, ce qui sera intéressant.


2
Bien fait, pour comprendre qu'il est toujours nécessaire de regarder le code source et de vérifier ce qui est fait!
igouy

1
Pour
connaître le

2
C'est exactement le genre de réponse que j'espérais, merci!
Greg Slodkowicz

Beaucoup moins d'utilisation de code et de mémoire, compile en code machine, mieux conçu. Tout cela prend le désavantage de la vitesse.
Moshe Revah

22
  1. Sans même dire quels problèmes ont été résolus, l’ensemble des critères est inutile.
  2. JVM et CLR utilisent tous les deux des JIT pour produire du code machine. Il n'y a aucune raison pour que cela soit plus lent. Cela ne vous coûte que des années pour démarrer.
  3. Go a été conçu pour construire rapidement . Vous n'avez pas des tonnes d'optimisations au moment de la compilation et du démarrage. Go compile sa propre bibliothèque standard au moment du démarrage d’une application Java.

Go pourrait-il être plus rapide au moment de l'exécution? Oui. Est-ce que Go sera toujours plus rapide au moment de l'exécution? Je ne sais pas. Peut-être que les constructeurs de compilateurs ajouteront une optimisation optionnelle au prix de la compilation. Mais je ne pense pas qu'ils s'intéressent beaucoup à cela. Ils travaillent chez Google.
Ce qu'ils veulent, c'est un langage qui permette un développement rapide et qui fonctionne bien dans ce qu'ils font. Enfer, même si ce repère était crédible, cela signifierait qu'ils sont moitié moins vite que C et 14 fois plus vite que Python. C'est plus qu'assez bon.
Le matériel est bon marché, le code est cher. Le code a tendance à devenir plus gros et plus lent au fur et à mesure que vous investissez de l'argent, le matériel devient moins cher et plus économique. Vous voulez un langage qui ne nécessite pas 4 frameworks et 2000 classes pour accomplir quoi que ce soit d’utile.
Il n'y a rien d'inhérent dans la conception de Go, cela le ralentit. Cependant, il y a quelque chose d'inhérent dans les concepteurs de Go, qui le rend plus lent que l'assemblage: le bon sens.


1
La plupart des JIT (tous?) Sont compilés pendant l'exécution, pas lors du premier chargement du code. Ce code machine peut ne pas être généré du tout pour certains codes et peut également être facilement invalidé, par exemple si objsin for (obj : objs) { obj.meth() }a différentes implémentations à methchaque fois et que le JIT tente de le mettre en ligne. Bien sûr, tout cela constitue un avantage dans les cas courants, mais reste digne d’être noté.

@delnan: Le JIT V8 utilise n'importe quel code avant de l'exécuter. En outre, la LLVM a été construite avec JITting à l’esprit, vous pouvez donc (avec quelques efforts bien sûr) effectuer toute optimisation juste à temps, ce qui se produirait sinon au moment de la compilation. Cependant, certaines optimisations, telles que l'analyse d'échappement, fonctionnent uniquement avec les JIT.
back2dos

3
>> Sans même dire quels problèmes ont été résolus << Regardez et vous constaterez que ces pages Web indiquent quels problèmes ont été résolus. En fait, vous trouverez le code source du programme, des commandes de construction, les commandes d'exécution, la version de l' implémentation du langage, ya da da ya ya
igouy

10

J'ai aussi remarqué que Go était particulièrement lent dans la référence regex-adn . Russ Cox a expliqué pourquoi Go n’était pas aussi performant dans ce critère . La raison en est que le paquetage regexp de Go utilise un algorithme de correspondance différent qui fonctionne mal dans ce cas-test particulier, mais qui pourrait être plus rapide dans d'autres cas. De plus, Ruby, Python et d’autres langages de script utilisent une implémentation C d’un autre algorithme de correspondance d’expression rationnelle .

Enfin, le jeu de repères de langage informatique consiste en micro-repères qui pourraient ne pas refléter avec précision de nombreuses caractéristiques des langages mesurés et même véhiculer des impressions erronées. Ce document de recherche, récemment publié par Google, donne un aperçu plus précis de plusieurs caractéristiques linguistiques de Go, Scala, Java et C ++ - en particulier de la partie "V. Performance Analysis". Donc, au final, Go consomme presque autant de mémoire que Java (81% de la mémoire de Java) et consomme même 170% de la mémoire de Scala (impossible de trouver dans le document si la consommation de mémoire de la machine virtuelle a été prise en compte).

Mais encore une fois, Go est jeune et est toujours en plein développement (changements d'API)! De nombreuses améliorations sont à venir.


3
>> Ce document de recherche, récemment publié par Google << Ce n'est pas un document de recherche et il n'a pas été publié par Google. Il s'agit d'un compte-rendu d'expérience présenté par un employé de Google lors de l'atelier Scala "Scala Days 2011".
igouy

>> pourrait ne pas refléter avec précision de nombreuses caractéristiques des langages mesurés et même éviter des impressions erronées << C'est tout aussi vrai pour les programmes de "reconnaissance de boucle", et probablement pour chaque comparaison de performances entre différents langages de programmation. En fait, l'auteur vous dit: "Nous n'explorons aucun aspect du multi-threading, ni des mécanismes de type supérieur ... nous n'effectuons pas non plus de calculs numériques lourds ..."
mercredi

@igouy Sur la couverture, vous pouvez lire "Google" et tout ce qui est pertinent est couvert des références correspondantes. Alors, pourquoi ne s'agit-il pas d'un "article de recherche publié par Google" si Google est mentionné avec l'adresse de son siège social? Les articles de recherche ne sont pas un domaine exclusivement académique.
Alex

Sur la couverture, vous pouvez lire l'adresse postale à laquelle l'auteur peut être contacté, ainsi que l'adresse électronique de l'auteur. Vérifiez l'URL du pdf que vous avez posté. Notez le domaine - days2011.scala-lang.org - l'atelier "Scala Days 2011" de Scala.
mercredi

1

Go est plus rapide que Python et un peu plus lent que Java. D'après mon expérience approximative, Go est beaucoup plus rapide (1 à 2 ordres de grandeur) que Python et environ 10 à 20% moins rapide que Java. Cependant, Go est légèrement plus rapide que Java s'il est utilisé avec quad-core (x64). Go est également beaucoup plus efficace en termes de mémoire RAM.

J'aimerais ajouter quelques points sur le potentiel de performance de Go par rapport à Java et à Python. Go permet plus de choses que C fait, ce qui permet constamment à C de surpasser la plupart des autres langages. Les erreurs de cache sont très importantes à éviter pour un code hautes performances. La réduction des erreurs de cache nécessite de contrôler la disposition de la mémoire de vos structures de données. Go vous permet de le faire. Java ne le fait pas, ce qui rend plus difficile d'éviter la fracture de la mémoire et du cache.

Actuellement, Java est généralement plus rapide que Go, car le récupérateur de déchets Java est beaucoup plus sophistiqué. Bien qu'il n'y ait pas de raison que le ramasse-miettes de Go ne pourrait pas être beaucoup mieux. La génération de code est également probablement bien meilleure pour Java pour le moment. Go a beaucoup de potentiel à améliorer, par exemple en prenant en charge les instructions vectorielles, etc.

Je pense donc que ce n’est vraiment qu’une question de temps avant que Go dépasse Java. Bien que comme avec toutes les langues, le code ne sera pas automatiquement plus rapide s'il est écrit en Go. Vous devez utiliser les installations que la langue vous donne. Je dirais que Go donne simplement plus de possibilités pour ajuster votre code.

Quoi qu'il en soit, ce n'est que l'expérience d'un développeur.


4
C'est une question vieille de 8 ans et la puissance de calcul peu coûteuse l'a rendue relativement inutile. Votre réponse est également basée sur "votre sentiment" plutôt que sur des données fiables. Je ne veux pas vous décourager, mais ...
Kayaman
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.