pourquoi le golang est plus lent que le scala?
Dans ce test , nous pouvons voir que les performances de golang sont parfois beaucoup plus lentes que scala. À mon avis, étant donné que le code de golang est compilé directement en code binaire compatible c/c ++, tandis que le code de scala est compilé en code octet JVM, golang devrait avoir des performances bien meilleures, en particulier dans ces algorithmes de calcul intensif que le benchmark a fait. Ma compréhension est-elle incorrecte?
Voici ce que je pense qui se passe dans les quatre benchmarks où les solutions go sont les plus lentes par rapport aux solutions scala.
- mandelbrot: l'implémentation scala a sa boucle interne déroulée une fois. Il se peut aussi que la JVM puisse vectoriser le calcul comme ceci, ce que le compilateur go ne pense pas C'est encore une bonne optimisation manuelle et un meilleur support JVM pour accélérer l'arithmétique.
- regex-dna: l'implémentation scala ne fait pas ce que le benchmark requiert: on lui demande de "" "(un motif à la fois) remplacer le motif dans le fichier de redirection, et enregistrez la longueur de la séquence "" "mais il s'agit simplement de calculer la longueur et d'imprimer cela. La version go fait le match-replace donc est plus lente.
- k-nucleotide: l'implémentation scala a été optimisée en utilisant le bit-twiddling pour regrouper les nucléotides dans un long plutôt que d'utiliser des caractères. C'est une bonne optimisation qui pourrait également être appliqué au code Go.
- arbres binaires: cela teste les performances de gc en remplissant la RAM. Il est vrai que Java gc est beaucoup plus rapide que le go gc, mais l'argument selon lequel ce n'est pas la priorité absolue pour go est que généralement on peut éviter le gc dans les programmes réels en ne produisant pas de déchets dans le première place.
Ce graphique provient de la séance de programmation. Vous devriez lire les clauses de non-responsabilité sur la page Shootout avant de prendre les repères comme gospel. Au mieux, ces repères ne sont utiles que pour indiquer de larges attentes de performance.
Cela dit, la JVM dispose d'une décennie d'optimisation bien financée et, en dehors du temps de démarrage, offre d'excellentes performances pour l'exécution de code. Le go est encore une langue jeune. Le fait que Go se trouve à distance de crachement d'un langage JVM est impressionnant. Si vous aimez la programmation dans Go, vous ne devez pas la rejeter sur une seule référence.
Ceci est discuté dans le go FAQ :
L'un des objectifs de conception de Go est d'approcher les performances de C pour des programmes comparables, mais sur certains benchmarks, il le fait assez mal, y compris plusieurs en test/bench/shootout. Les plus lents dépendent des bibliothèques pour lesquelles des versions de performances comparables ne sont pas disponibles dans Go. Par exemple, pidigits.go dépend d'un package mathématique multi-précision, et les versions C, contrairement à Go, utilisent GMP (qui est écrit dans un assembleur optimisé). Les repères qui dépendent des expressions régulières (regex-dna.go, par exemple) comparent essentiellement le package regexp natif de Go à des bibliothèques d'expressions régulières matures et hautement optimisées comme PCRE.
Les jeux de référence sont gagnés par un réglage approfondi et les versions Go de la plupart des références nécessitent une attention particulière. Si vous mesurez des programmes C et Go comparables (reverse-complément.go en est un exemple), vous verrez que les deux langues sont beaucoup plus proches en performances brutes que ne l'indique cette suite.
Il y a encore place à amélioration. Les compilateurs sont bons mais pourraient être meilleurs, de nombreuses bibliothèques nécessitent un travail de performance majeur et le garbage collector n'est pas encore assez rapide. (Même si c'était le cas, prendre soin de ne pas générer de déchets inutiles peut avoir un effet énorme.)
Soit dit en passant, considérons la différence de vitesse 10x (!) Entre les différentes versions d'une référence pour un langage de programmation donné. C gcc # 7 est 8,3 fois plus lent que C gcc # 5, et Ada # 3 presque 10 fois plus lent que Ada # 5. Ces repères fournissent une idée approximative de la façon dont le langage se compare, mais la différence entre Go et Scala est dans un ordre de grandeur, ce qui signifie que toute variation "intrinsèque" entre les temps d'exécution est susceptible d'être éclipsée par différences dans l'implémentation: cet article décrit comment ils ont accéléré un programme 11x en effectuant une allocation de mémoire plus intelligente. Peut-être que le compilateur/runtime devrait gérer ce type d'optimisations automatiquement (comme le fait la JVM, jusqu'à un certain niveau), mais je ne suis pas sûr que vous puissiez vraiment tirer la conclusion que "Go est plus lent (resp. plus rapide) que Scala" dans le cas général de ces chiffres. Juste mon avis cependant :)
Puisque vous semblez vouloir examiner ces repères biaisés. Prenons un exemple réel pour un scénario réel et non certaines implémentations de Fibonacci.
Jetez un œil à ces classements pour les référentiels de frameworks Web, les tests ont été effectués en utilisant un client natif si disponible et parfois en utilisant des frameworks Web OSS, ils utilisent également de nombreux packages pour les tests avec le même langage. Les tests varient des demandes de chaînes brutes à l'utilisation d'ORM pour interroger une base de données.
Il est clair que Scala les performances ne sont pas si proches de Go, dans tous les tests Scala était en dessous de Go. Cela dit, les repères ne sont rien près de réalité et je vous suggère de regarder un langage du point de vue des outils/fonctionnalités ou simplement ce qui serait le mieux pour résoudre votre problème.
Comme Brad l'a souligné, ces résultats proviennent d'une suite de référence particulière. Cela fournit certaines informations , mais ne présumez pas que c'est l'image entière. Il serait utile de savoir si le code source est suffisamment bien écrit dans chaque cas pour donner la vitesse la plus rapide, le moins d’utilisation de mémoire ou un autre objectif cible.
Nous pourrions peut-être comparer avec un autre site Web qui classe les langues. Jetez un œil à http://www.techempower.com/benchmarks/ dans lequel les codes de service Web sont comparés. En dépit d'être une langue jeune, Go est l'un des meilleurs dans certains de ces repères.
Comme dans tous les benchmarks, cela dépend toujours de ce que vous recherchez et de la façon dont vous le mesurez.