VS2008 C ++优化器有时会产生较慢的代码吗? [英] Does the VS2008 C++ optimizer sometimes produce slower code?

问题描述

根据上一个问题，我一直在玩在我的发行版本中使用优化器设置，以了解使用编译器优化可带来哪些好处.到目前为止，我一直在使用/Ob1(仅在显式给出内联的情况下为inline)和/Oi(启用内在函数).我尝试将其更改为包括/Ot(最喜欢的快速代码)，/Oy(省略帧指针)和/Ob2(内联任何合适的行)，令我惊讶的是，一个花了2h58分钟的回归套件现在花了3h16m.我的第一个假设是我自己的内联比编译器更具侵略性，但是从/Ob2移到/Ob1只会将事情改进到3h12m.我仍在运行更多测试，但似乎在某些情况下/Ot(较喜欢的快速代码)实际上正在减慢速度.该软件是多线程且计算量大的(曲面建模，操作和可视化)，并且已经基于探查器结果进行了大量的手动优化.该程序还处理大量数据，并非常定期地使用#pragma pack(4).

Following on from a previous question, I've been playing around with optimizer settings in my release build to see what benefits are to be gleaned from using compiler optimization. Up until now, I've been using /Ob1 (only inline where inline is explicitly given), and /Oi (Enable intrinsic functions). I tried changing this to include /Ot (favour fast code), /Oy (omit frame pointers) and /Ob2 (inline any suitable), and to my surprise a regression suite that was taking 2h58 minutes now took 3h16m. My first assumption was that my own inlining was more aggressive than the compiler, but moving back from /Ob2 to /Ob1 only improved things to 3h12m. I'm still running more tests, but it would appear that in some cases /Ot (favour fast code) is actually slowing things down. The software is multi-threaded and computation intensive (surface modelling, manipulation and visualisation), and has already been heavily manually optimized based on profiler results. The program is also dealing with large amounts of data, and uses #pragma pack(4) pretty regularly.

所以问题是这样.对于手动优化的程序，VS2008中的编译器优化是否有弊大于利?换句话说，是否存在已知的已记录的方案，其中编译器优化会降低性能? (n.b.对编译器优化的代码进行性能分析很麻烦，因此迄今为止，对未优化的代码进行了性能分析.)

So the questions is this. For a manually optimized program is compiler optimization in VS2008 liable to do more damage than good? Put another way, are there known documented scenarios where compiler optimization reduces performance? (n.b. profiling the compiler optimized code is painful, hence profiling to date has been done on unoptimized code).

编辑根据Cody Gray的建议和其他建议，我已将/O2添加到优化设置中并重新执行了我的测试套件.这样得出的运行时间为3h01，与最低优化运行相当.鉴于(略过时)关于优化的MSDN指南并从GOZ发布，我将检查/O1以查看在我的情况下较小的速度实际上是否更快.请注意，当前的EXE文件约为11mb.我还将尝试将VS2010构建在一起，并观察其发展情况.

Edit As per Cody Gray's and others suggestions, I have added /O2 to the optimization settings and re-executed my test suite. This resulted in a run time of 3h01, which was comparable to the minimally optimized run. Given the (slightly dated) MSDN guide lines on optimization and post from GOZ, I'm going to check /O1 to see if smaller is actually faster in my case. Note the current EXE file is about ~11mb. I'll also try and get a VS2010 build together and see how that fares.

Edit2 使用/O1，运行时间为3h00，而11mb exe缩小了62k.请注意，本文和上一个链接的文章背后的原因是，检查在进行概要分析和调试方面，启用编译器优化的好处是否超过了缺点.在这种特定情况下，它们似乎不是，尽管我承认令所有尝试的组合都没有任何好处或显着降低性能的情况感到惊讶. FWIW，根据上一个线程，我倾向于进行大部分优化在设计时，主要使用探查器检查设计假设，我认为我会坚持使用这种方法.我将在启用整个程序优化的VS2010上做最后一件事，然后将其保留.

Edit2 With /O1, the run time was 3h00, and the 11mb exe was 62k smaller. Note that the reason behind this post, and the previous linked one, were to check whether the benefits of turning on compiler optimizations outweighed the drawbacks in terms of profiling and debugging. In this specific instance, they appear not to be, although I admit to being surprised that none of the combinations tried added any benefit and some visibly reduced performance. FWIW, as per this previous thread, I tend to do most of my optimization at design time and use the profiler primarily to check design assumptions, I reckon I'll be sticking with this approach. I'll have one final go on VS2010 with whole program optimization enabled and leave it at that.

感谢所有反馈！

推荐答案

文档用于/Ot状态:

如果使用/Os或/Ot，则还必须指定/Og来优化代码.

If you use /Os or /Ot, then you must also specify /Og to optimize the code.

因此，您可能希望在测试中始终将/Og和/Ot通过.

So you might want to always pass /Og with /Ot in your tests.

也就是说，/Ot倾向于以程序大小为代价的快速代码，并且可以产生非常大的二进制文件，尤其是内联繁重的代码.大型二进制文件很难利用处理器缓存.

That said, /Ot favors fast code at the expense of program size, and can produce very large binaries, especially with heavy inlining. Large binaries have difficulties to take advantage of the processor cache.

这篇关于VS2008 C ++优化器有时会产生较慢的代码吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！