为什么 golang 比 scala 慢？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/20875341/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
why golang is slower than scala?
提问by Tyr
In this test, we can see that the performance of golang is sometimes much slower than scala. In my opinion, since the code of golang is compiled directly to c/c++ compatible binary code, while the code of scala is compiled to JVM byte code, golang should have much better performance, especially in these computation-intensive algorithm the benchmark did. Is my understanding incorrect?
在这个测试中，我们可以看到golang的性能有时比scala慢很多。在我看来，既然golang的代码是直接编译成c/c++兼容的二进制代码，而scala的代码是编译成JVM字节码的，那么golang的性能应该会好很多，尤其是benchmark做的这些计算密集型的算法。我的理解有误吗？
回答by Paul Hankin
Here's what I think's going on in the four benchmarks where the go solutions are the slowest compared to the scala solutions.
这是我认为在四个基准测试中发生的事情，其中 go 解决方案与 scala 解决方案相比最慢。
- mandelbrot: the scala implementation has its internal loop unrolled one time. It may be also that the JVM can vectorise the calculation like this, which I think the go compiler doesn't yet do. This is good manual optimisation plus better JVM support for speeding arithmetic.
- regex-dna: the scala implementation isn't doing what the benchmark requires: it's asked to """(one pattern at a time) match-replace the pattern in the redirect file, and record the sequence length""" but it's just calculating the length and printing that. The go version does the match-replace so is slower.
- k-nucleotide: the scala implementation has been optimised by using bit-twiddling to pack nucleotides into a long rather than use chars. It's a good optimisation that could also be applied to the Go code.
- binary-trees: this tests gc performance by filling RAM. It's true that java gc is much faster than the go gc, but the argument for this not being the top priority for go is that usually one can avoid gc in real programs by not producing garbage in the first place.
- mandelbrot：Scala 实现的内部循环展开了一次。也可能是 JVM 可以像这样矢量化计算，我认为 go 编译器还没有这样做。这是很好的手动优化加上对加速算法更好的 JVM 支持。
- regex-dna：scala 实现没有按照基准测试的要求执行：它被要求“”“（一次一个模式）匹配替换重定向文件中的模式，并记录序列长度“””但它只是计算长度并打印出来。go 版本进行匹配替换，因此速度较慢。
- k-核苷酸：scala 实现已经通过使用 bit-twiddling 将核苷酸打包成 long 而不是使用字符进行了优化。这是一个很好的优化，也可以应用于 Go 代码。
- 二叉树：这通过填充 RAM 来测试 gc 性能。java gc 确实比 go gc 快得多，但是这不是 go 的首要任务的论点是，通常可以通过首先不产生垃圾来避免实际程序中的 gc。
回答by Brad Clawsie
This chart is from the Programming Shootout. You should read the disclaimers on the Shootout page before taking the benchmarks as gospel. At best these benchmarks are only useful for indicating broad expectations of performance.
该图表来自编程枪战。在将基准作为福音之前，您应该阅读 Shootout 页面上的免责声明。这些基准充其量仅用于表明对性能的广泛期望。
That said, the JVM has a decade of well-funded optimization and apart from startup time, provides excellent performance for running code. Go is still a young language. The fact that Go comes within spitting distance of a JVM language is impressive. If you enjoy programming in Go, you should not reject it over one benchmark.
也就是说，JVM 拥有十年资金充足的优化，除了启动时间外，还为运行代码提供了出色的性能。Go 仍然是一门年轻的语言。Go 接近 JVM 语言的事实令人印象深刻。如果你喜欢用 Go 编程，你不应该因为一个基准而拒绝它。
回答by val
This is discussed in the go FAQ:
这在 go FAQ 中讨论：
One of Go's design goals is to approach the performance of C for comparable programs, yet on some benchmarks it does quite poorly, including several in test/bench/shootout. The slowest depend on libraries for which versions of comparable performance are not available in Go. For instance, pidigits.go depends on a multi-precision math package, and the C versions, unlike Go's, use GMP (which is written in optimized assembler). Benchmarks that depend on regular expressions (regex-dna.go, for instance) are essentially comparing Go's native regexp package to mature, highly optimized regular expression libraries like PCRE.
Benchmark games are won by extensive tuning and the Go versions of most of the benchmarks need attention. If you measure comparable C and Go programs (reverse-complement.go is one example), you'll see the two languages are much closer in raw performance than this suite would indicate.
Still, there is room for improvement. The compilers are good but could be better, many libraries need major performance work, and the garbage collector isn't fast enough yet. (Even if it were, taking care not to generate unnecessary garbage can have a huge effect.)
Go 的设计目标之一是在类似程序中接近 C 的性能，但在某些基准测试中它的表现相当糟糕，包括测试/基准测试/枪战中的几个。最慢的取决于在 Go 中没有可比性能版本的库。例如，pidigits.go 依赖于多精度数学包，而 C 版本与 Go 不同，使用 GMP（用优化的汇编程序编写）。依赖于正则表达式的基准测试（例如 regex-dna.go）本质上是将 Go 的原生 regexp 包与成熟的、高度优化的正则表达式库（如 PCRE）进行比较。
基准游戏是通过广泛的调整赢得的，大多数基准的围棋版本需要注意。如果您测量可比较的 C 和 Go 程序（reverse-complement.go 是一个示例），您会发现这两种语言的原始性能比该套件显示的要接近得多。
尽管如此，仍有改进的余地。编译器很好但可以更好，许多库需要主要的性能工作，垃圾收集器还不够快。（即使是这样，注意不要产生不必要的垃圾也会产生巨大的影响。）
As an aside, consider the 10x (!) speed difference between the different versions of a benchmarkfor a given programming language. C gcc #7 is 8.3 times slower than C gcc #5, and Ada #3 almost 10 times slower than Ada #5. These benchmarks provide a rough idea of how language compare, but the difference between Go and Scala is within one order of magnitude, which means any 'intrinsic' variation between the runtimes is likely to be dwarfed by differences in the implementation: this postdescribes how they sped up a program 11x by performing smarter memory allocation. Maybe the compiler/runtime should be handling this kind of optimisations automatically (as the JVM does, to a certain level), but I am not sure you can really draw the conclusion that 'Go is slower (resp. faster) than Scala' in the general case from these figures. Just my opinion though :)
顺便说一句，请考虑给定编程语言的基准测试的不同版本之间的 10 倍（！）速度差异。C gcc #7 比 C gcc #5 慢 8.3 倍，Ada #3 比 Ada #5 慢近 10 倍。这些基准测试提供了语言如何比较的粗略概念，但 Go 和 Scala 之间的差异在一个数量级内，这意味着运行时之间的任何“内在”变化都可能被实现的差异相形见绌：这篇文章描述了他们如何通过执行更智能的内存分配来加速程序 11 倍。也许编译器/运行时应该自动处理这种优化（就像 JVM 所做的那样，在一定程度上），但我不确定你是否真的能得出这样的结论：“Go 比 Scala 更慢（或者更快）”这些数字的一般情况。只是我的意见:)
回答by ymg
Since you seem to be keen in looking at these biased benchmarks. Let's take a real example for real scenario not some Fibonacci implementations.
因为您似乎热衷于查看这些有偏见的基准。让我们为真实场景而不是一些斐波那契实现举一个真实的例子。
Take a look at these rankings for web frameworks benchmarks, the testing was done using native client if available and sometimes using OSS web frameworks, they also use many packages for testing with the same language. The tests vary from requests for raw strings to using ORM to query a database.
看看这些Web 框架基准排名，测试是使用本机客户端（如果可用）完成的，有时使用 OSS Web 框架，他们还使用许多包进行相同语言的测试。测试从对原始字符串的请求到使用 ORM 查询数据库不等。
It is clear that Scala performance is no where close to Go, in all of the tests Scala was below Go. Having said this, benchmarks are nothing close to reality and I suggest you look at a language from tools/features perspective or simply what would be best to solve your problem.
很明显，Scala 的性能远不及 Go，在所有测试中 Scala 都低于 Go。话虽如此，基准测试并不接近现实，我建议您从工具/功能的角度来看一门语言，或者只是什么最能解决您的问题。
回答by Rick-777
As Brad pointed out, these results are from one particular benchmark suite. This provides someinformation, but don't assume it's the whole picture. It would be helpful to know whether the source code is well enough written in each case to give the fastest speed, the least memory use, or some other target goal.
正如 Brad 指出的那样，这些结果来自一个特定的基准测试套件。这提供了一些信息，但不要假设它是全貌。了解源代码是否在每种情况下都编写得足够好以提供最快的速度、最少的内存使用或其他一些目标目标会很有帮助。
Perhaps we might compare with another website that ranks languages. Take a look at http://www.techempower.com/benchmarks/in which web service codes are compared. In spite of being a young language, Go is one of the best in some of these benchmarks.
也许我们可以与另一个对语言进行排名的网站进行比较。查看http://www.techempower.com/benchmarks/，其中比较了 Web 服务代码。尽管 Go 是一门年轻的语言，但在其中一些基准测试中，Go 是最好的语言之一。
As in all benchmarks, it always depends what you strive for and how you measure it.
与所有基准测试一样，它始终取决于您追求的目标以及衡量它的方式。
