PGO 比静态优化慢（intel 编译器）答案

【问题标题】：PGO slower than static optimization (intel compiler)PGO 比静态优化慢（intel 编译器）
【发布时间】：2012-07-21 15:36:33
【问题描述】：

我正在为 I-32A 架构使用英特尔 C 编译器。当我使用以下选项编译我的 C 程序时：

icl mytest.c /openmp /QxHost /fp:fast /fast

测试运行需要 3.3 秒。现在我尝试使用PGO，所以我编译了：

icl mytest.c /openmp /QxHost /fp:fast /fast /Qprof-gen

然后我使用示例输入运行可执行文件 2-3 次，然后再次编译：

icl mytest.c /openmp /QxHost /fp:fast /fast /Qprof-use

希望它会考虑收集到的信息。事实上，它告诉我它正在使用 .dyn 文件，但生成的可执行文件比没有使用 Qprof 时要慢（3.85 秒），而且这与执行运行的数据完全相同（对于 PGO 来说应该是完美的）。我尝试将 openmp 线程设置为一个，认为它可能会与 .dyn 输出混淆，但结果是一样的 - 它比简单编译要慢。

我的问题是：这在理论上是否可行，或者我用编译器选项以某种方式搞乱了 PGO 进程？

【问题讨论】：

/Qpprof-use?第二个 p 应该在那里吗？
只是一个错字；打字比从控制台复制粘贴要快:)

标签： c optimization icc

【解决方案1】：

3.3 秒的浮点应用程序不会从配置文件引导的优化中受益。根据我的猜测，您正在进行某种原始数据处理，如果您需要原始 FLOP，则它更适合手动编码汇编，而不是 PGO。

PGO 不会告诉编译器如何优化您的内部循环以消除分支延迟并保持管道满。它可能告诉它您的循环是否可能只运行 5,000 次，或者您的浮点数是否满足某些条件。

它用于在统计上代表您希望它运行的其他数据的数据。换句话说，您将它与程序上的数据一起使用，您希望能够以良好的剪辑运行其他数据。它不一定针对手头的程序进行优化，正如您所说，甚至可能会减慢它的速度以获得可能的净收益。

这确实取决于您的程序，但 OpenMP FP 应用程序不是 PGO 的用途。像其他一切一样，它不是“灵丹妙药”。

【讨论】：

谢谢，这很有帮助。我仍然很惊讶它对运行配置文件的完全相同的数据给出了更差的结果。对此有什么解释吗？
@PiotrLopusiewicz 是的。就像我说的那样，它可能会确定您的循环通常会在 5,000 次迭代后终止。如果这样做，它将添加代码以检查大约 5,000 次迭代的终止条件。它基本上会添加启发式方法来加速平均预测情况，不一定是您肯定正在运行的情况，例如 qsort 性能是如何摊销的。顺便说一句，循环只是一个简单的例子。