1

我正在为 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 文件,但生成的可执行文件比没有使用 Qpr​​of 时要慢(3.85 秒),而且这与执行运行的数据完全相同(对于 PGO 来说应该是完美的)。我尝试将 openmp 线程设置为一个,认为它可能会与 .dyn 输出混淆,但结果是相同的 - 它比简单编译慢。

我的问题是:这在理论上是否可行,或者我用编译器选项以某种方式搞砸了 PGO 进程?

4

1 回答 1

1

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

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

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

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

于 2012-07-21T16:04:28.377 回答