/Ox 和/O2 编译器选项之间有什么区别?
Microsoft 的 C++ 编译器(cl.exe
,包含在 Visual Studio 中)提供 几个优化开关.它们中的大多数之间的区别似乎不言自明,但我不清楚 /O2
(优化代码以获得最大速度)和 /Ox
(选择完全优化").
Microsoft's C++ compiler (cl.exe
, as included with Visual Studio) offers several optimization switches. The difference between most of them seems self-explanatory, but it's not clear to me what the difference is between /O2
(which optimizes code for maximum speed) and /Ox
(which selects "full optimization").
我已经尝试阅读 文档 的 /Ox
选项,它似乎确认此开关还可以优化最大速度,而不是大小:
I've tried reading the documentation for the /Ox
option, and it seems to confirm that this switch also enables optimizations for maximum speed, rather than size:
/Ox
编译器选项生成的代码有利于执行速度而不是较小的尺寸.
The
/Ox
compiler option produces code that favors execution speed over smaller size.
但特别是,备注"部分下的以下声明引起了我的注意:
But in particular, the following statement under the "Remarks" section caught my eye:
通常,指定/O2
(最大化速度)而不是/Ox
.
In general, specify
/O2
(Maximize Speed) instead of/Ox
.
所以我的问题是,为什么人们普遍偏爱 /O2
而不是 /Ox
? 后一个选项是否启用了已知的特定优化导致不可预见的错误或其他意外行为?是否只是要获得的优化量不值得额外的编译时间?或者这只是一个完全没有意义的推荐",因为 /O2
是 VS 中的默认选项?
So my question is, why should one generally favor /O2
over /Ox
? Does the latter option enable a particular optimization known to cause unforeseen bugs or otherwise unexpected behavior? Is it simply that the amount of optimization to be gained is not worth the additional compile time? Or is this just a completely meaningless "recommendation" resulting from the fact that /O2
is the default option in VS?
推荐答案
Asha 的回答 引用了一篇关于 Visual Studio 2005 的博客文章,而且已经过时了.
Asha's answer cites a blog post about Visual Studio 2005, and is rather out of date.
最新版本的文档可在此处获得:
The latest version of the documentation is available here:
/Ox
:https://msdn.microsoft.com/en-us/library/59a3b321.aspx/O2
:https://msdn.microsoft.com/en-us/library/8f8h5cxt.aspx
根据那些:
/Ox
→/Og/Oi/Ot/Oy/Ob2
/O2
→相同,但进一步添加/Gs/GF/Gy
/Ox
→/Og /Oi /Ot /Oy /Ob2
/O2
→ the same, but further adds/Gs /GF /Gy
/GF
消除重复字符串/Gy
执行函数级链接
您可能还对 /GS-
感兴趣,它会关闭堆栈周围的安全检查,这可能会严重影响性能(请参阅 /GS 的 MS 文档).
You may additionally be interested in /GS-
which turns off security checks around the stack, which can be a significant performance hit (see the MS docs for /GS).
您应该一如既往地对您的特定应用程序进行基准测试.
You should benchmark your specific application, as ever.
相关文章