0

我在 SPEC 基准测试中对 GCC Profile-Guided Optimization 的开销进行了基准测试。我在一些基准测试中得到了一些奇怪的结果。事实上，我的两个基准测试在检测时运行得更快。

正常的可执行文件使用以下命令编译： -g -O2 -march=native

检测的可执行文件使用以下命令编译： -g -O2 -march=native -fprofile-generate -fno-vpt

我正在使用 GCC 4.7（准确地说是 Google 分支）。运行基准测试的计算机具有 Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz。

bwaves 是 Fortran 基准测试和 libquantum

结果如下：

bwaves-normal: 712.14 
bwaves-instrumented: 697.22 
  => ~2% faster 

libquantum-normal: 463.88
libquantum-instrumented: 449.05
  => ~3.2% faster

我多次运行基准测试，认为这可能是 ma 机器上的问题，但每次我都确认它们。

我会理解某些程序的开销很小，但我看不出有任何改进的理由。

所以我的问题是：GCC 检测的可执行文件如何比优化的普通可执行文件更快？

谢谢

4

2 回答 2

1

查看 GCC 文档，它似乎-fprofile-generate确实激活了一些特定的代码转换以使分析更容易/更便宜，因此检测代码并不是真正的原始代码 + 检测。这些更改可以使代码更快，添加代码也会使缓存行为发生变化。如果没有看到有问题的代码，很难知道。从我（很久以前）玩弄LCC开始，当智能分析完成时，它涉及的代码更改非常少。

只是好奇：与上述相比，考虑到配置文件编译的代码如何？

于 2013-01-31T12:41:43.730 回答
1

我可以想到两种可能性，都与缓存有关。

一是计数器增量“温暖”了一些重要的缓存行。其次，添加检测所需的结构会导致一些频繁使用的数组或变量落入不同的缓存行。

另一个问题是，在 for 循环中不必每次都进行分析/增加计数器 - 如果循环中没有“中断”或“返回”，则允许编译器优化循环外的增量。

于 2013-01-31T14:16:17.283 回答