c - 双重编译 C 代码以减少执行时间

Question

根据 this文章/视频:

GCC recognizes several architecture-dependent optimizations for increasing the speed of C executables. Passing an executable through GCC a second time can often provide a dramatic performance improvement.

如果您观看了链接上的视频，您会发现此方法使可执行文件的速度加倍。我不确定这是否普遍。

我的问题是:为什么会这样？

奖励:当我们重新编译一个已编译的程序时会发生什么？

Answer 1

这是一个骗局。

gcc 和任何其他编译器都无法读取目标代码、“编译”它并生成更快的目标代码。

最接近的是反馈导向编译，您首先使用仪器编译程序(例如 gcc --fprofile-generate)，运行该程序，生成有关运行的数据文件(例如foo.gcda)，然后使用相同的源代码和数据文件再次编译程序作为编译器的输入(例如 gcc --fprofile-use)。这会导致相当适度的加速，根据我的经验，通常在 5% 到 10% 之间。

假设您有一个由 50 个 if … else if 结构组成的长链(不适合重组为 switch)。例如，这经常发生在蒙特卡罗模拟中。如果您是一位相当有经验的程序员，您可能会对这些进行排序，以便最常使用的分支首先出现。这个想法是，在运行时，您不会在考虑最有可能的分支之前浪费时间考虑 30 个不太可能的分支。此外，您将尝试从最有可能到最不可能对这些分支进行排序，以便平均而言，在找到正确的分支测试之前执行的分支测试数量最少。

请注意，编译器没有对这些分支进行排序的依据，因为一个分支比另一个更有可能的信息根本不在源代码中，因此最好的办法是按源代码顺序输出分支。

使用经典的反馈导向编译，您首先创建可执行文件的检测版本(当您运行它时)记录每个分支被(或不被)数据文件的次数。第二次编译时，编译器从运行时(它通常没有)获得经验数据，可用于重新排序测试并插入分支提示，这将使代码运行得更快……至少具有与分析测试程序相似的工作负载。

我确信现代的反馈导向编译要复杂得多，但这是一般的想法。