2009-11-04 112 views
7

具有用于使用反馈优化不同的节目没有人见过任何真实世界的数字,C/C++编译器提供支持分支预测,缓存预加载功能等C/C++编译器反馈优化

我搜索了它甚至令人惊讶的是,甚至连流行的翻译发展集团似乎都没有检查这种效果。增加10%左右的ruby,python,php等性能应该被认为是有用的。

真的没有任何好处,或者整个开发者社区只是为了懒得使用它吗?

+1

我相信你正在寻找的词是'简介指导优化'。我不知道任何发布前后测量的重大项目,但我知道Firefox在其构建系统中支持PGO。请参阅https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization – int3

+0

非正式地,我已经在嵌入式代码基础上看到了+ 10%,但从未见过任何正式的PGO研究。 –

回答

6

10%是一个很好的球场数字。这就是说,...

你必须真正关心走这条路线的表现。我工作的产品(DB2)使用PGO和其他侵入式和侵略性优化。其中包括大量的构建时间(在某些平台上为三倍)以及开发和支持噩梦。

当出现问题时,将优化代码中的故障位置映射回源代码可能并不重要。开发人员通常不会期望不同模块中的函数最终可能会合并和内联,并且可能会产生“有趣”的效果。

与指针别名问题,这是讨厌跟踪也通常显示与这些优化。你有非确定性构建的附加乐趣(在周一的构建中会出现别名问题,直到星期四再次消失,...)。

在这些积极的优化下,正确或不正确的编译器行为之间的界限也变得相当模糊。即使让我们的编译器家族(字面上的)优化问题(无论是在我们的源代码还是编译器中)仍然不易理解和解决。

+1

这个。 PGO是快速迭代的致命的敌人,你不能仅仅为了测试而离开它,因为每隔一段时间它就会引入一个bug。这并不是说没有任何好处,但与大多数应用程序的开发和支持成本相比,性能增益是微不足道的。 –

+1

好吧把大卫。如果你使用主要的版本边界来使编译器更新准备好让这些优化在几个月后不能工作(可能会在GA日期附近再次运行;)。并准备好行为稳定的服务发布版本,以突然开始行为异常。并且,... 为什么这不常见可能归结为金钱。在产品中使用PGO会有很大的人员配置费用。 –

+2

请注意,PGO通常不会引入错误,而是_exposes_,_finds_或_trips over_ bugs。 – MSalters

1

通过性能分析工具完成通过分析来提高编译器效率的传统方法。但是,工具中的数据如何用于优化仍然取决于您使用的编译器。例如,GCC是一个正在为不同领域生成编译器的框架。在这样的编译器框架中提供分析机制将非常困难。

我们可以依靠统计数据做一定的优化。例如,如果循环计数小于常数(例如7),则GCC展开一个循环。它如何修复常量将基于针对不同目标体系结构生成的代码大小的统计结果。

简介指导性优化跟踪源的特殊领域。有关之前运行结果的详细信息需要存储,这是一个开销。另一方面,输入需要统计表示可能使用编译器的目标应用程序。所以复杂度随着不同输入和输出的数量而增加。简而言之,决定简介指导优化需要极端的数据收集。自动化或将此类分析嵌入源代码需要仔细监控。否则,整个结果将会出错,而我们努力游泳,我们实际上会淹死。

但是,这方面的实验正在进行中。只需看看POGO

3

unladen-swallow(一期工程优化CPython的VM):与海湾合作委员会的定向反馈优化工具实验时

对于我们来说,在PyBench的棺材上的最后一颗钉子是,我们能够生产出通用15%我们的macrobenchmarks性能提升;使用相同的培训工作量,PyBench慢了10%。

所以有些人至少看着它。也就是说,PGO对构建环境设置了一些非常棘手的要求,这些要求很难满足由分布式异构人员构建的开源项目。重度优化还会导致难以调试heisenbugs。给编译器提供性能关键部分的显式提示的工作量较小。

也就是说,我期望从运行时配置文件指导优化中显着提高性能。 JIT'ing允许优化器处理程序执行过程中数据变化的轮廓,并执行许多极其运行时数据特定的优化,从而为静态编译提高代码大小。特别是动态语言需要良好的基于​​运行时数据的优化才能运行良好随着动态语言性能在近期得到了广泛的关注(JavaScript VM,MS DLR,JSR-292,PyPy等),这方面还有很多工作要做。