从2010年的计算机语言基准游戏中可以看出:
考虑到Go编译器会生成要执行的本机代码,这怎么可能? Go的编译器不成熟?还是Go语言存在一些内在问题?
编辑: 大多数答案否认Go语言的内在缓慢,声称问题出在不成熟的编译器中。 因此,我进行了一些自己的测试来计算斐波那契数:迭代算法在Go(freebsd,6g)中以与sameC(带有O3选项)一样的速度运行。迟钝的递归代码在Go中的运行2 times速度比C慢(使用-O3选项;使用-O0-相同)。但是我还没有看到基准测试中出现10倍的下降。
same
2 times
6g和8g编译器并不是特别优化,因此它们生成的代码并不是特别快。
它们旨在快速运行自己并生成可以的代码(有些优化)。gccgo使用GCC的现有优化遍历,并可能与C进行更有意义的比较,但是gccgo尚未完成功能。
gccgo
基准数字几乎完全与执行质量有关。它们与这种语言没有太多关系,除非实现花费了运行时支持基准测试实际上不需要的语言功能。从理论上讲,在大多数编译语言中,足够聪明的编译器可以剔除不需要的内容,但是您到了要演示的地方,因为很少有真正的语言用户编写不使用该功能的程序。 。将事情移开而不完全删除它们(例如,在JIT编译的Java中预测虚拟调用目标)开始变得棘手。
FWIW是我自己用Go进行的非常琐碎的测试(基本上是整数加法循环),gccgo朝着介于C gcc -O0和gcc -O2C 之间的范围的高端输出了代码。Go 并不是天生就很慢,但是编译器还不能做所有事情。对于10分钟的语言来说,这不足为奇。
gcc -O0
gcc -O2