在g ++中优化级别-O3是否危险？ [英] Is optimisation level -O3 dangerous in g++?
问题描述
我听说过各种来源（虽然主要是来自我的同事），用 -O3 在 g ++ 在某种程度上是危险的，除非证明是必要的，否则应该避免。
这是真的吗？我应该只是坚持 -O2 ？
天的gcc（2.8等）和在egcs的时代，和redhat 2.96 -O3有时是相当bug。但这是十多年前，-O3与其他级别的优化（在buggyness）没有太大的不同。
但它倾向于揭示人们依赖的情况对于未定义的行为，由于更严格地依赖于规则，特别是语言的角落情况。
作为个人注意，我正在运行生产软件在金融部门多年来与-O3，还没有遇到一个错误，如果我将使用-O2。如果没有使用。
根据受欢迎的需求，这里添加：
-O3，尤其是像-funroll-loops（-O3不启用）这样的附加标志有时会导致生成更多的机器码。在某些情况下（例如，在具有特别小的L1指令高速缓存的cpu上），这可能导致由于例如所有代码的减速。一些内循环现在不再适合L1I。通常gcc尝试相当难以不生成这么多的代码，但由于它通常优化通用情况，这可能发生。特别易于出现的选项（如循环展开）通常不包括在-O3中，并在手册页中相应地标记。因此，使用-O3来生成快速代码通常是个好主意，并且仅当适当时（例如，当分析器指示L1I未命中时），才回退到-O2或-Os（其试图优化代码大小） p>
如果你想将优化带到极端，你可以通过--param在gcc中调整与某些优化相关的成本。另外请注意，gcc现在有能力把属性放在控制优化设置的功能，只是为这些功能，所以当你发现你有一个问题-O3在一个函数（或想试试特殊的标志只是那个函数）你不需要编译整个文件，甚至整个项目与O2。
otoh似乎在使用-Ofast时必须小心，其中规定： p>
-Ofast启用所有-O3优化。
它还启用对所有标准
兼容程序无效的优化。
这使我得出结论： -O3旨在完全符合标准。
I have heard from various sources (though mostly from a colleague of mine), that compiling with an optimisation level of -O3 in g++ is somehow 'dangerous', and should be avoided in general unless proven to be necessary.
Is this true, and if so, why? Should I just be sticking to -O2?
In the early days of gcc (2.8 etc.) and in the times of egcs, and redhat 2.96 -O3 was quite buggy sometimes. But this is over a decade ago, and -O3 is not much different than other levels of optimizations (in buggyness).
It does however tend to reveal cases where people rely on undefined behavior, due to relying more strictly on the rules, and especially corner cases, of the language(s).
As a personal note, I am running production software in the financial sector for many years now with -O3 and have not yet encountered a bug that would not have been there if I would have used -O2.
By popular demand, here an addition:
-O3 and especially additional flags like -funroll-loops (not enabled by -O3) can sometimes lead to more machine code being generated. Under certain circumstances (e.g. on a cpu with exceptionally small L1 instruction cache) this can cause a slowdown due to all the code of e.g. some inner loop now not fitting anymore into L1I. Generally gcc tries quite hard to not to generate so much code, but since it usually optimizes the generic case, this can happen. Options especially prone to this (like loop unrolling) are normally not included in -O3 and are marked accordingly in the manpage. As such it is generally a good idea to use -O3 for generating fast code, and only fall back to -O2 or -Os (which tries to optimize for code size) when appropriate (e.g. when a profiler indicates L1I misses).
If you want to take optimization into the extreme, you can tweak in gcc via --param the costs associated with certain optimizations. Additionally note that gcc now has the ability to put attributes at functions that control optimization settings just for these functions, so when you find you have a problem with -O3 in one function (or want to try out special flags for just that function), you don't need to compile the whole file or even whole project with O2.
otoh it seems that care must be taken when using -Ofast, which states:
-Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard compliant programs.
which makes me conclude that -O3 is intended to be fully standards compliant.
这篇关于在g ++中优化级别-O3是否危险？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
