PGO比静态优化慢(英特尔编译器)

Question

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

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

测试运行需要3.3s。现在我尝试使用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.85s)，并且这是在执行运行的完全相同的数据上执行的(对于PGO来说应该是完美的)。我尝试将openmp线程设置为一个线程，认为它可能会影响.dyn输出，但结果是一样的--它比简单的编译要慢。

，我的问题是：从理论上讲，这是可能的吗?还是我用编译器选项搞砸了PGO过程？

Answer 1

一个3.3秒的浮点应用程序不会从概要文件引导的优化中获益。根据我的猜测，您正在进行某种原始数据处理，如果您需要原始失败而不是PGO，则更适合手工编写程序集。

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

它与在统计上代表您希望运行的其他数据的数据一起使用。换句话说，您使用它的数据，在一个程序中，您希望能够运行其他数据在一个良好的剪辑。它不一定要对手头的程序进行优化，而且，正如您所说的那样，它可能会放慢一些速度，以获得可能的净收益。

它确实取决于您的程序，但OpenMP FP应用程序并不是PGO的用途。就像所有其他东西一样，它不是“魔法子弹”。