有人知道这个编译器功能吗？GCC 似乎支持这一点。它是如何工作的？潜在收益是多少？在什么情况下好？内循环？
（这个问题是具体的，而不是一般的优化，谢谢）
elmarco
问问题
4846 次
4 回答
12
它通过放置额外的代码来计算每个代码路径的使用次数。当你第二次编译时，编译器会使用之前只能猜测的关于程序执行的知识。PGO 可以做以下几件事：
- 根据调用频率决定哪些函数应该被内联或不被内联。
- 根据以一种方式或另一种方式进行的调用的百分比来决定如何放置关于“if”语句的哪个分支应该被预测的提示。
- 根据每次调用循环时进行的迭代次数来决定如何优化循环。
在您进行测试之前，您永远不会真正知道这些东西有多大帮助。
于 2008-09-11T20:34:45.913 回答
6
PGO gives about a 5% speed boost when compiling x264, the project I work on, and we have a built-in system for it (make fprofiled). Its a nice free speed boost in some cases, and probably helps more in applications that, unlike x264, are less made up of handwritten assembly.
于 2008-09-16T12:14:58.430 回答
4
杰森的建议是正确的。您将获得的最佳加速来自“发现”您让 O(n 2 ) 算法滑入某处的内部循环，或者您可以在昂贵的函数之外缓存某些计算。
与 PGO 可以触发的微优化相比，这些是最大的赢家。一旦您完成了该级别的优化，PGO 可能会提供帮助。不过，我们从来没有运气好过——仪器的成本使得我们的应用程序变得非常慢（几个数量级）。
我喜欢使用英特尔 VTune 作为分析器，主要是因为与检测分析器相比，它是非侵入性的，因为它会改变太多的行为。
于 2008-09-09T18:49:24.047 回答
2
优化的有趣之处在于，在最不可能的地方发现速度增益。
这也是您需要分析器的原因，而不是猜测速度问题出在哪里。
我建议从分析器开始（gperf如果您使用的是 GCC），然后开始通过一些正常操作来查看运行应用程序的结果。
于 2008-09-09T18:43:01.923 回答