您通常如何设置编译器的优化设置？
您通常是否将编译器设置为优化最大速度或最小代码大小？ 或者您手动配置单独的优化设置？ 为什么？
我注意到大多数时候人们倾向于将编译器优化设置保留为默认状态，这对于 Visual C++ 意味着最大速度。 我一直认为默认设置更多地与基准测试中的外观有关，这些程序往往是完全适合 L2 缓存的小程序，而不是最适合整体性能的程序，因此我通常将其优化为最小尺寸。
Do you normally set your compiler to optimize for maximum speed or smallest code size? or do you manually configure individual optimization settings? Why?
I notice most of the time people tend to just leave compiler optimization settings to their default state, which with visual c++ means max speed.
I've always felt that the default settings had more to do with looking good on benchmarks, which tend to be small programs that will fit entirely within the L2 cache than what's best for overall performance, so I normally set it optimize for smallest size.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
现在内存很便宜:) 因此，除非您使用嵌入式系统，否则将编译器设置设置为最大速度是有意义的。 当然答案要看具体情况。
Memory is cheap now days :) So it can be meaningful to set compiler settings to max speed unless you work with embedded systems. Of course answer depends on concrete situation.
这取决于您的程序的应用。 当对应用程序进行编程以控制快速工业过程时，优化速度是有意义的。 当编写只需要对用户输入做出反应的应用程序时，优化大小可能是有意义的。 也就是说，如果您担心可执行文件的大小。
This depends on the application of your program. When programming an application to control a fast industrial process, optimize for speed would make sense. When programming an application that only needs to react to a user's input, optimization for size could make sense. That is, if you are concerned about the size of your executable.
像这样调整编译器设置是一种优化。 根据“过早的优化是万恶之源”的原则，直到程序接近其最终交付状态并且我发现它不够快时我才开始关心它——即几乎从来没有。
Tweaking compiler settings like that is an optimization. On the principle that "premature optimization is the root of all evil," I don't bother with it until the program is near its final shipping state and I've discovered that it's not fast enough -- i.e. almost never.
构建两者，配置文件，选择哪个在特定项目和硬件上效果更好。
对于性能关键的代码，也就是说 - 否则选择任何一个并且不用打扰。
Build both, profile, choose which works better on specific project and hardware.
For performance critical code, that is - otherwise choose any and don't bother.
我们总是使用最大化来获得最佳速度，但是，我用 C++ 编写的所有代码都在某种程度上与生物信息学算法相关，并且速度至关重要，而代码大小相对较小。
We always use maximize for optimal speed but then, all the code I write in C++ is somehow related to bioinformatics algorithms and speed is crucial while the code size is relatively small.
Microsoft 发布的所有 C/C++ 软件都针对大小进行了优化。 经过基准测试后，他们发现它实际上提供了更好的速度（由于缓存局部性）。
Microsoft ships all its C/C++ software optimized for size. After benchmarking they discovered that it actually gives better speed (due to cache locality).
优化有很多种类型，最大速度与小代码只是其中之一。 在这种情况下，我会选择最大速度，因为可执行文件会更大一些。
另一方面，您可以针对特定类型的处理器优化您的应用程序。 在某些情况下，这是一个好主意（如果您打算仅在您的工作站上运行该程序），但在这种情况下，该程序可能无法在其他体系结构上运行（例如：您将程序编译为在奔腾上运行） 4 机器 -> 它可能无法在 Pentium 3 上运行）。
There are many types of optimization, maximum speed versus small code is just one. In this case, I'd choose maximum speed, as the executable will be just a bit bigger.
On the other hand, you could optimize your application for a specific type of processor. In some cases this is a good idea (if you intend to run the program only on your station), but in this case it is probable that the program will not work on other architecture (eg: you compile your program to work on a Pentium 4 machine -> it will probably not work on a Pentium 3).
我更喜欢使用最小尺寸。 内存可能很便宜，缓存则不然。
I prefer to use minimal size. Memory may be cheap, cache is not.
除了缓存位置很重要这一事实（正如 On Freund 所说）之外，微软所做的另一件事是分析他们的应用程序并找出在启动的前几秒内执行的代码路径。 之后，他们将这些数据反馈给编译器，并要求它将启动期间执行的部分放在一起。 这会导致更快的启动时间。
我确实相信这种技术在 VS 中是公开可用的，但我不是 100% 确定。
Besides the fact that cache locality matters (as On Freund said), one other things Microsoft does is to profile their application and find out which code paths are executed during the first few seconds of startup. After that they feed this data back to the compiler and ask it to put the parts which are executed during startup close together. This results in faster startup time.
I do believe that this technique is available publicly in VS, but I'm not 100% sure.
对我来说，这取决于我使用的平台。 对于某些嵌入式平台或当我在 Cell 处理器上工作时，您会受到一些限制，例如非常小的缓存或为代码提供的最小空间。
我使用 GCC 并且倾向于将其保留在“-O2”上，这是“最安全”的优化级别，并且更注重速度而不是最小的大小。
我想说，除非您正在开发非常高性能的应用程序，否则它可能不会产生巨大的差异，在这种情况下，您可能应该针对您的特定用例对各种选项进行基准测试。
For me it depends on what platform I'm using. For some embedded platforms or when I worked on the Cell processor you have restraints such as a very small cache or minimal space provided for code.
I use GCC and tend to leave it on "-O2" which is the "safest" level of optimisation and favours speed over a minimal size.
I'd say it probably doesn't make a huge difference unless you are developing for a very high-performance application in which case you should probably be benchmarking the various options for your particular use-case.
作为一名 Gentoo 用户，我在整个操作系统上尝试了相当多的优化，并且在 Gentoo 论坛 关于它。 一些 GCC 的好标志可以在 wiki 中找到。
简而言之，优化尺寸在内存有限的旧 Pentium3 笔记本电脑上效果最佳，但在我的配备 Core2Duo 的主台式机上，-O2 总体上给出了更好的结果。
如果您对 x86（32 位）特定标志感兴趣，还有一个 小脚本最优化的。
如果您使用 gcc 并且确实想要优化特定应用程序，请尝试 ACOVEA。 它运行一组基准测试，然后使用编译标志的所有可能组合重新编译它们。 网站上有一个使用霍夫曼编码的示例（越低越好）：（
请注意，它发现 -Os 在此 Opteron 系统上是最慢的。）
As a Gentoo user I have tried quite a few optimizations on the complete OS and there have been endless discussions on the Gentoo forums about it. Some good flags for GCC can be found in the wiki.
In short, optimizing for size worked best on an old Pentium3 laptop with limited ram, but on my main desktop machine with a Core2Duo, -O2 gave better results over all.
There's also a small script if you are interested in the x86 (32 bit) specific flags that are the most optimized.
If you use gcc and really want to optimize a specific application, try ACOVEA. It runs a set of benchmarks, then recompile them with all possible combinations of compile flags. There's an example using Huffman encoding on the site (lower is better):
(Note that it found -Os to be the slowest on this Opteron system.)