有没有人见过不同程序的真实世界数字，这些程序使用 C/C++ 编译器提供的反馈优化来支持分支预测、缓存预加载功能等。
我搜索了它，令人惊讶的是，即使是流行的解释器开发小组似乎也没有检查过效果。并且将 ruby、python、php 等性能提高 10% 左右应该被认为是有用的。
真的没有好处，还是整个开发者社区都懒得用？
【问题讨论】：
标签： c++ c optimization gcc compiler-construction
10% 是一个不错的数字。也就是说，...
您必须真正关心性能才能走这条路。我从事的产品 (DB2) 使用 PGO 和其他侵入性和积极的优化。其中的成本包括大量的构建时间（在某些平台上是三倍）以及开发和支持噩梦。
当出现问题时，将优化代码中的故障位置映射回源代码并非易事。开发人员通常不期望不同模块中的函数最终会合并和内联，这会产生“有趣”的效果。
指针别名问题（很难追踪）通常也会出现在这些优化中。您还可以通过非确定性构建获得额外的乐趣（混叠问题可能会出现在周一的构建中，直到周四再次消失......）。
在这些激进的优化下，正确或错误的编译器行为之间的界限也变得相当模糊。即使有我们的编译器人员在内部（字面意思）的奢侈，优化问题（在我们的源代码或编译器中）仍然不容易理解和解决。
【讨论】：
通过分析提高编译器效率的传统方法是通过性能分析工具完成的。但是，来自工具的数据如何用于优化仍然取决于您使用的编译器。例如，GCC 是一个正在开发的框架，用于为不同的域生成编译器。在这样的编译器框架中提供分析机制将非常困难。
我们可以依靠统计数据做一定的优化。例如，如果循环计数小于一个常数（比如 7），GCC 会展开一个循环。它如何修复常数将基于为不同目标架构生成的代码大小的统计结果。
配置文件引导优化跟踪源的特殊区域。需要存储有关先前运行结果的详细信息，这是一种开销。另一方面，输入需要可以使用编译器的目标应用程序的统计表示。因此，复杂性级别随着不同输入和输出的数量而上升。简而言之，决定配置文件引导优化需要极端的数据收集。自动化或将此类分析嵌入源代码需要仔细监控。否则，整个结果将是错误的，在我们努力游泳时，我们实际上会淹死。
但是，这方面的实验正在进行中。看看POGO。
【讨论】：
来自unladen-swallow（一个优化CPython VM的项目）：
对我们来说，PyBench 棺材中的最后一颗钉子是在试验 gcc 的反馈导向优化工具时，我们能够在我们的宏观基准测试中实现 15% 的通用性能提升；使用相同的训练工作量，PyBench 的速度降低了 10%。
所以至少有些人在看它。也就是说，PGO 对构建环境设置了一些非常棘手的要求，对于旨在由分布式异构群体构建的开源项目来说，这些要求很难满足。重度优化也会造成难以调试的 heisenbugs。为性能关键部分提供编译器显式提示会减少工作量。
也就是说，我预计运行时配置文件引导的优化会显着提高性能。 JIT'ing 允许优化器处理在程序执行过程中发生变化的数据配置文件，并进行许多极其运行时数据特定的优化，这些优化会增加静态编译的代码大小。特别是动态语言需要良好的基于运行时数据的优化才能表现良好。随着动态语言性能最近受到极大关注（JavaScript VM's、MS DLR、JSR-292、PyPy 等），这方面有很多工作要做。
【讨论】：