有人知道这个编译器功能吗? GCC似乎支持这一点。它是如何工作的?潜在收益是多少?在哪种情况下它很好?内环?
(这个问题具体,一般不是优化,谢谢)
答案 0 :(得分:12)
它通过放置额外的代码来计算每个代码路径的计数次数。当你第二次编译时,编译器使用获得的关于程序执行的知识,它只能在之前猜到。 PGO可以为之努力:
在测试之前,你真的不知道这些东西有多大帮助。
答案 1 :(得分:6)
PGO在编译我工作的项目x264时提供了大约5%的速度提升,我们有一个内置的系统(make fprofiled)。在某些情况下,这是一个不错的免费速度提升,并且可能有助于更多的应用程序,与x264不同,它们更少由手写组件组成。
答案 2 :(得分:4)
杰森的建议是正确的。你将获得的最佳加速来自“发现”你让O(n 2 )算法滑入某个内部循环,或者你可以在昂贵的函数之外缓存某些计算。 / p>
与PGO可以触发的微观优化相比,这些是大赢家。一旦你完成了这种优化水平,PGO可能会提供帮助。我们从来没有过多运气 - 仪器的成本使我们的应用变得非常缓慢(几个数量级)。
我喜欢使用英特尔VTune作为分析器,主要是因为与仪器分析器相比,它是非侵入性的,因为它可以改变行为。
答案 3 :(得分:2)
优化的有趣之处在于可以在最不可能的地方找到速度提升。
这也是你需要一个分析器的原因,而不是猜测速度问题在哪里。
我建议您使用分析器(gperf
,如果您正在使用GCC),并开始通过一些正常操作来查看运行应用程序的结果。