问为什么Go这么慢(与Java相比)？

EN

6g和8g编译器不是特别优化，所以它们产生的代码不是特别快。

它们的设计初衷是让它们自己运行得很快，并生成没问题的代码(有一些优化)。gccgo使用了GCC现有的优化通道，并可能提供与C更有意义的比较，但gccgo的功能还不完整。

基准数字几乎完全是关于实施质量的。它们与语言本身没有太多的关系，除非实现花费了运行时来支持基准测试并不真正需要的语言特性。在大多数编译语言中，足够聪明的编译器在理论上可以剔除不需要的东西，但总有一天你会操纵演示，因为很少有真正的语言用户会编写不使用该功能的程序。在不完全移除它们的情况下移动它们(例如，在JIT编译的Java中预测虚拟调用目的地)开始变得棘手。

FWIW，我自己对Go进行的非常简单的测试(基本上是一个整数加法循环)，gccgo生成的代码接近gcc -O0和gcc -O2之间的等价物C的快端。Go本身并不慢，但编译器还不能做所有的事情。对于一门只有10分钟历史的语言来说，这并不令人惊讶。

在Go FAQ的下一个版本中，应该会出现类似以下内容的内容。

性能

为什么Go在benchmark X上表现不佳？

Go的设计目标之一是在可比程序中接近C的性能，但在一些基准测试中，它表现得相当差，包括在测试/基准测试中的几个。最慢的依赖于Go中没有可比性能版本的库。例如，pidigits依赖于多精度数学包，而C版本与Go版本不同，它使用GMP (它是用优化的汇编程序编写的)。依赖于正则表达式(例如regex-dna)的基准测试实质上是将Go的临时regexp包与成熟的、高度优化的正则表达式库(如PCRE )进行比较。

基准游戏是通过广泛的调整赢得的，大多数基准游戏的Go版本都需要关注。如果你测量可比较的C和Go程序(反向补码就是一个例子)，你会发现这两种语言的原始性能比这个套件所显示的要接近得多。

尽管如此，仍有改进的空间。编译器很好，但可以更好，许多库需要主要的性能工作，垃圾收集器还不够快(即使它足够快，注意不要生成不必要的垃圾可能会产生巨大的影响)。

下面是最近一个邮件列表线程中关于The Computer Benchmarks Game的更多细节。

Garbage collection and performance in gccgo (1)

Garbage collection and performance in gccgo (2)

需要注意的是，Computer Benchmarks只是一个游戏。在性能测量和容量规划方面有经验的人会仔细地与现实和实际的工作负载进行匹配；他们不玩游戏。

我的答案并不像其他人的答案那样技术性，但我认为它仍然是相关的。当我决定开始学习围棋时，我在计算机基准游戏中看到了同样的基准。但老实说，我认为所有这些综合基准在决定Go对你来说是否足够快方面是毫无意义的。

我最近使用Tornado+TornadIO+ZMQ用Python语言编写了一个消息服务器，对于我的第一个Go项目，我决定用Go重写服务器。到目前为止，已经让服务器实现了与Python版本相同的功能，我的测试显示Go程序的速度提高了4.7倍。请注意，我用Go编写代码大概只有一周的时间，而我用Python编写代码已经超过5年了。

随着他们继续努力，Go只会变得更快，我认为这真的归结于它在现实世界应用程序中的表现，而不是微小的计算基准。对我来说，Go显然比我在Python中生成的程序更有效。这就是我对这个问题的回答。