【发布时间】：2013-02-25 17:41:17
【问题描述】：
我相信知道golang 的每个人都知道blog post 在这里。
再读一遍，我想知道使用gccgo 代替go build 是否会提高速度。在我的典型用例（科学计算）中，gccgo 生成的二进制文件总是比go build 生成的二进制文件快。
所以，只需获取这个文件：havlak6.go 并编译它：
go build havlak6.go -O havlak6_go
gccgo -o havlak6_gccgo -march=native -Ofast havlak6.go
惊喜！
$/usr/bin/time ./havlak6_go
5.45user 0.06system 0:05.54elapsed 99%CPU
$/usr/bin/time ./havlak6_gccgo
11.38user 0.16system 0:11.74elapsed 98%CPU
我很好奇，想知道为什么“优化”编译器会产生较慢的代码。
我尝试在gccgo 生成的二进制文件上使用gprof：
gccgo -pg -march=native -Ofast havlak6.go
./a.out
gprof a.out gmon.out
没有运气：
Flat profile:
Each sample counts as 0.01 seconds.
no time accumulated
如您所见，代码实际上并未被分析。
当然，我读过this，但正如你所见，程序执行需要10+秒...样本数应该> 1000。
我也试过了：
rm a.out gmon.out
LDFLAGS='-g -pg' gccgo -g -pg -march=native -Ofast havlak6.go
./a.out
gprof
也没有成功。
你知道有什么问题吗？在这种情况下，您知道为什么 gccgo 及其所有优化例程都不能比 gc 快吗？
go 版本：1.0.2
gcc 版本：4.7.2
编辑：
哦，我完全忘了提...我显然在gccgo生成的二进制文件上尝试了pprof...这是top10：
Welcome to pprof! For help, type 'help'.
(pprof) top10
Total: 1143 samples
1143 100.0% 100.0% 1143 100.0% 0x00007fbfb04cf1f4
0 0.0% 100.0% 890 77.9% 0x00007fbfaf81101e
0 0.0% 100.0% 4 0.3% 0x00007fbfaf8deb64
0 0.0% 100.0% 1 0.1% 0x00007fbfaf8f2faf
0 0.0% 100.0% 3 0.3% 0x00007fbfaf8f2fc5
0 0.0% 100.0% 1 0.1% 0x00007fbfaf8f2fc9
0 0.0% 100.0% 1 0.1% 0x00007fbfaf8f2fd6
0 0.0% 100.0% 1 0.1% 0x00007fbfaf8f2fdf
0 0.0% 100.0% 2 0.2% 0x00007fbfaf8f4a2f
0 0.0% 100.0% 1 0.1% 0x00007fbfaf8f4a33
这就是我寻找其他东西的原因。
EDIT2：
由于似乎有人希望我的问题被关闭，我没有尝试使用 gprof 出乎意料：https://groups.google.com/d/msg/golang-nuts/1xESoT5Xcd0/bpMvxQeJguMJ
【问题讨论】：
-
人们仍然believe in gprof as the canonical profiler.。几点： 1) gprof 仅对具有浅调用堆栈的 CPU 绑定程序有用，没有递归，它具有所有符号。 2) 编译器优化只对紧密的内部循环或在您的代码中调用很多的例程产生影响，这些例程本身并不调用函数（如内存分配等）。编译器优化不仅仅是让一切变得更快。
-
是的，我为 gprof 得到了它。我同意你对编译器优化的看法。但是，我不希望使用具有优化能力的编译器获得更差的性能。性能应该相等或更好。如果没有，还有改进的余地，我想了解原因:)
-
我唯一做过的时间是端到端的，可能重复 10^n 次并除以它，我不寻找超过 3 位数的准确度。有噪音，我不在乎。然后我使用随机暂停来寻找让它更快的方法。除非它已经像海绵一样被挤压了，否则我会想办法，然后我可以从头再来。当几个周期后我遇到收益递减，并且 pc 最常出现在我生成的指令中时，然后我打开优化器，这可能使其速度提高 10%。哎呀。