AK_*_*AK_ 7 c optimization performance gcc
根据这篇文章/视频:
GCC认识到几种与体系结构相关的优化,以提高C可执行文件的速度.通过GCC第二次传递可执行文件通常可以提供显着的性能改进.
如果您在链接上观看了视频,则可以看到此方法使可执行文件的速度加倍.我不确定这是否一般.
我的问题是:为什么会这样？
额外奖励:当我们完全重新编译已编译的程序时会发生什么？
Emm*_*met 46
这是骗局.
gcc任何其他编译器都不能读取目标代码,"编译"它,并生成更快的目标代码.
最接近的是反馈导向编译,您首先使用检测(例如gcc --fprofile-generate)编译程序,运行该程序,生成关于运行的数据文件(例如foo.gcda),然后使用相同的源代码和数据再次编译程序file作为编译器的输入(例如gcc --fprofile-use).这可以导致相当适度的加速,在我的经验中通常在5%到10%之间.
假设您有一个包含50个if … else if构造的长链(不适合重构为a switch).例如,这通常发生在蒙特卡罗模拟中.如果您是一位经验丰富的程序员,您可能会订购这些程序员,以便最常出现的分支首先出现.我们的想法是,在运行时,在考虑最可能的分支之前,不要浪费时间考虑30个不太可能的分支.此外,您将尝试从最可能最不可能的顺序对这些分支进行排序,以便平均而言,在找到正确的分支测试之前执行最少数量的分支测试.
请注意,编译器没有对这些分支进行排序的依据,因为一个更可能的信息不在源代码中,因此可以做的最好的事情是按源顺序输出分支.
使用经典的反馈导向编译,首先创建一个可执行文件的检测版本(当您运行它时)记录每个分支被采用(或不采用)到数据文件的次数.编译第二次,编译器从经验数据运行(它通常没有),可以用来重新排序测试和插入分支提示,这将使代码运行得更快......至少有类似于异形测试工作量程序.
我确信现代反馈导向的编译要复杂得多,但这是一般的想法.