c++ - 我什么时候可以自信地使用 -O3 编译程序？

Question

我看到很多人提示 -O3 选项:

• GCC: program doesn't work with compilation option -O3
• Floating Point Problem provided by David Hammen

我查看 GCC 的手册:

   -O3    Optimize yet more.  -O3 turns on all optimizations
          specified   by   -O2   and   also   turns  on  the
          -finline-functions and -frename-registers options.

而且我还确认了代码，以确保两个选项是 -O3 中仅有的两个优化:

if (optimize >= 3){
    flag_inline_functions = 1;
    flag_rename_registers = 1;
}

对于这两个优化:

• -finline-functions 在某些情况下(主要是 C++)很有用，因为它允许我们使用 -finline-limit 定义内联函数的大小(默认为 600)。设置高内联限制时，编译器可能会报告内存不足的错误。
• -frename-registers 尝试通过使用寄存器分配后剩余的寄存器来避免预定代码中的错误依赖。这种优化最有利于具有大量寄存器的处理器。

对于inline-functions，虽然它可以减少函数调用的次数，但是它可能会导致一个大的二进制文件，所以-finline-functions可能会引入严重的缓存惩罚并且变得比-O2。我认为缓存惩罚不仅取决于程序本身。

对于重命名寄存器，我认为它不会对像 x86 这样的 cisc 架构产生任何积极影响。

我的问题有 2.5 个部分:

1. 我是否可以声称使用 -O3 选项可以更快地运行程序取决于底层平台/架构？ [已回答]

   编辑:

   第一部分已确认为真。 David Hammen 还声称，我们应该非常小心优化和浮点运算如何在具有扩展精度浮点寄存器的机器(如 Intel 和 AMD)上交互。

2. 我什么时候可以自信地使用 -O3 选项？我想这两个优化，尤其是重命名寄存器可能会导致与 -O0/O2 不同的行为.我看到一些使用 -O3 编译的程序在执行过程中崩溃了，这是确定性的吗？如果我运行一次可执行文件而没有任何崩溃，这是否意味着使用 -O3 是安全的？

   编辑:确定性与优化无关，它是一个多线程问题。但是，对于多线程程序，当我们运行一次可执行文件而没有错误时，使用 -O3 是不安全的。 David Hammen 表明，-O3 对浮点运算的优化可能会违反严格的比较弱排序标准。 使用-O3选项还有什么需要注意的地方吗？

3. 如果第一个问题的答案是"is"，那么当我更改目标平台或在具有不同机器的分布式系统中时，我可能需要在 -O3 和-O2。有什么通用的方法可以决定我是否可以通过 -O3 获得性能改进？比如寄存器多，内联函数短等等。[已回答]

   编辑:第 3 部分已被 Louen 回答为“平台的多样性使得对这个问题的一般推理变得不可能”在评估 -O3 的性能增益时，我们必须同时尝试并对我们的代码进行基准测试，看看哪个更快。

Answer 1

2. I saw some programs got crashed when compiling with -O3, is it deterministic?

如果程序是单线程的，程序使用的所有算法都是确定性的，并且如果每次运行的输入相同，是的。如果这些条件中的任何一个不成立，答案是“不一定”。

如果您不使用 -O3 进行编译，这同样适用。

If I run an executable once without any crash, does it mean it is safe to use -O3?

当然不是。同样，如果您不使用 -O3 进行编译，同样适用。仅仅因为您的应用程序运行一次并不意味着它在所有情况下都能成功运行。这是使测试成为难题的部分原因。

浮点运算可能会在浮点寄存器比 double 精度更高的机器上导致奇怪的行为。例如，

void add (double a, double b, double & result) {
   double temp = a + b;
   result = temp;
   if (result != temp) {
      throw FunkyAdditionError (temp);
   }
}

编译一个使用这个 add 的程序功能未优化，您可能永远不会看到任何 FunkyAdditionError异常(exception)。编译优化和某些输入会突然开始导致这些异常。问题是通过优化，编译器会生成 temp注册 result ，作为引用，不会被编译到寄存器中。添加 inline当您的编译器使用 -O3 编译时，限定符和这些异常可能会消失因为现在result也可以是寄存器。浮点运算的优化可能是一个棘手的问题。

最后，让我们看一下其中一个案例，当使用 -O3，GCC: program doesn't work with compilation option -O3 编译程序时，事情确实在晚上发生了变化。 .该问题仅出现在 -O3 中，因为编译器可能内联了 distance函数，但将其中一个(但不是两个)结果保存在扩展精度浮点寄存器中。通过此优化，某些点 p1和 p2可以导致 p1<p2和 p2<p1评估为 true .这违反了比较函数的严格弱排序标准。

您需要非常小心优化和浮点运算如何在具有扩展精度浮点寄存器的机器(例如 Intel 和 AMD)上交互。