Question

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.

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).

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 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.

Thanks for all the feedback!

Answer 1

The documentation for /Ot states:

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

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

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.