Combien de temps peut aller aller?

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.

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.

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.

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.

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.