performance - 编译器完成的配置文件引导的优化是否会严重损害性能分析数据集未涵盖的情况？

Question

这个问题不是特定于C++的，AFAIK某些运行时(例如Java RE)可以即时进行配置文件引导的优化，我对此也很感兴趣。

MSDN describes PGO像这样:

我检测我的程序并在分析器下运行，然后

编译器使用探查器收集的数据自动重新组织分支和循环，从而减少了分支的错误预测，并且经常将运行的代码紧凑地放置以改善其局部性

现在显然，分析结果将取决于所使用的数据集。

通过常规的手动配置和优化，我会发现一些瓶颈并改善这些瓶颈，并可能使所有其他代码保持不变。 PGO似乎可以改善经常运行的代码，但会降低很少运行的代码的速度。

现在，如果减慢的代码经常在程序在现实世界中看到的另一个数据集上运行，该怎么办？与没有PGO编译的程序相比，程序性能是否会下降？下降的可能性有多严重？换句话说，PGO是否真的提高了我的性能分析数据集的代码性能，并且可能使其他数据集的性能降低了？有没有带有真实数据的真实示例？

Answer 1

免责声明:我对PGO所做的工作不多，但请仔细阅读并通过一个示例项目尝试一次，以获取乐趣。以下是基于我对“非PGO”优化和有根据的猜测的经验。 TL; DR在下面。
This page列出了PGO完成的优化。让我们一一看一下(按影响分组):

Inlining – For example, if there exists a function A that frequently calls function B, and function B is relatively small, then profile-guided optimizations will inline function B in function A.

Register Allocation – Optimizing with profile data results in better register allocation.

Virtual Call Speculation – If a virtual call, or other call through a function pointer, frequently targets a certain function, a profile-guided optimization can insert a conditionally-executed direct call to the frequently-targeted function, and the direct call can be inlined.

这些显然改善了预测，无论某些优化是否奏效。对于未分析的代码路径，没有直接的权衡。

Basic Block Optimization – Basic block optimization allows commonly executed basic blocks that temporally execute within a given frame to be placed in the same set of pages (locality). This minimizes the number of pages used, thus minimizing memory overhead.

Function Layout – Based on the call graph and profiled caller/callee behavior, functions that tend to be along the same execution path are placed in the same section.

Dead Code Separation – Code that is not called during profiling is moved to a special section that is appended to the end of the set of sections. This effectively keeps this section out of the often-used pages.

EH Code Separation – The EH code, being exceptionally executed, can often be moved to a separate section when profile-guided optimizations can determine that the exceptions occur only on exceptional conditions.

所有这些可能会降低未分析的代码路径的局部性。以我的经验，如果此代码路径的紧密循环确实超过了L1代码缓存(甚至可能超过L2)，那么影响将是明显的或严重的。这听起来像是应该包含在PGO配置文件中的路径:)
死代码分离可能会产生巨大的影响(双向影响)，因为这会减少磁盘访问。
如果您依赖于快速的异常，那么您做错了。

Size/Speed Optimization – Functions where the program spends a lot of time can be optimized for speed.

如今的经验法则是“默认情况下优化大小，仅在需要时优化速度(并验证它是否有帮助)。原因再次是代码缓存-在大多数情况下，较小的代码也将是较快的代码，因为与全局速度优化相比，这只会在非常不典型的情况下(“奇怪的代码”或具有异常缓存行为的目标计算机)减慢未配置的代码路径的速度。

Conditional Branch Optimization – With the value probes, profile-guided optimizations can find if a given value in a switch statement is used more often than other values. This value can then be pulled out of the switch statement. The same can be done with if/else instructions where the optimizer can order the if/else so that either the if or else block is placed first depending on which block is more frequently true.

除非您输入错误的PGO信息，否则我也会将其提交给“改进的预测”。
运行时参数/范围验证以及在正常执行中绝对不应采用的类似路径可能会为此付出很大的代价。
破例是:

if (x > 0) DoThis() else DoThat();

在相关的紧密循环 和中，仅分析x> 0的情况。

Memory Intrinsics – The expansion of intrinsics can be decided better if it can be determined if an intrinsic is called frequently. An intrinsic can also be optimized based on the block size of moves or copies.

同样，大多数情况下是更好的信息，很少会对未经测试的数据进行惩罚。
示例:-这都是“有根据的猜测”，但是对于整个主题，我认为这是非常说明性的。
假设您有一个 memmove，它始终在长度为16个字节的对齐良好的非重叠缓冲区上被调用。
一种可能的优化是验证这些条件，并在这种情况下使用内联MOV指令，仅在不满足条件时才调用常规 memmove(处理对齐，重叠和奇数长度)。
在改善结构的局限性，减少预期的路径指令时，这种好处在复制结构的紧密循环中可能非常重要，这可能会带来更多的配对/重新排序的机会。
但是，相比而言，代价却很小:在没有PGO的一般情况下，您要么总是调用完整的memmove，要么使用nline完整的memmove的实现。该优化向相当复杂的内容添加了一些指令(包括条件跳转)，我假设最多会产生10％的开销。在大多数情况下，由于高速缓存访​​问，这10％会低于噪音。
但是，如果频繁使用意外分支，则极有可能产生重大影响 和预期情况的其他指令以及默认情况的指令将紧密循环推到L1代码缓存之外
请注意，您已经处于编译器可以为您做的极限。与代码高速缓存中的几个K相比，可以预期这些附加指令为几个字节。静态优化器可能会遇到同样的命运，具体取决于它可以如何提升不变量-以及您允许它多少。

结论:

许多优化是中性的。

一些优化可能会对未分析的代码路径产生轻微的负面影响

的影响通常比

可能带来的 yield 小得多

极少数情况下，其他促成病理因素可以强调很小的影响

很少有优化(即代码段的布局)会产生很大的影响，但是可能的 yield 再次大大超过了

我的直觉会进一步声称

总体而言，静态优化器至少有可能会创建病理情况

即使PGO输入不正确，实际上也很难破坏性能。

在那个级别上，我会比PGO优化失败更害怕PGO实现错误/缺点。