C/C++ Optimization
-
In the VS IDE (C/C++ Optimization), I usually set these optimizations for Release builds: Optimization: Maximize Speed (/O2) Inline Function Expansion: Any suitable (/Ob2) Enable Intrinsic Functions: Yes (/Oi) Favor Size or Speed: Favor Fast Code (/Ot) Omit Frame Pointers: No Enable Fiber-safe Optimizations: No Whole Program Optimization: No What settings do you use? Has anyone had any good/bad experiences with these settings? Have you found any helpful blogs as to which settings to use?
Best wishes, Hans
-
In the VS IDE (C/C++ Optimization), I usually set these optimizations for Release builds: Optimization: Maximize Speed (/O2) Inline Function Expansion: Any suitable (/Ob2) Enable Intrinsic Functions: Yes (/Oi) Favor Size or Speed: Favor Fast Code (/Ot) Omit Frame Pointers: No Enable Fiber-safe Optimizations: No Whole Program Optimization: No What settings do you use? Has anyone had any good/bad experiences with these settings? Have you found any helpful blogs as to which settings to use?
Best wishes, Hans
Hans Dietrich wrote:
Whole Program Optimization: No
Why do you have this option set to "No"?
Steve
-
Hans Dietrich wrote:
Whole Program Optimization: No
Why do you have this option set to "No"?
Steve
Mainly due to personal experience. I was trying to track down an intermittent crash that seemingly moved from one area of the app to another. A co-worker suggested removing /GL because it had caused him a similar problem. At this point I was grabbing for anything, so I removed /GL, and that was the last I saw of that crash. I wish I had a better justification, but I don't. There didn't seem to be any noticeable speed slowdown when /GL was removed, so I didn't pursue it.
Best wishes, Hans
-
In the VS IDE (C/C++ Optimization), I usually set these optimizations for Release builds: Optimization: Maximize Speed (/O2) Inline Function Expansion: Any suitable (/Ob2) Enable Intrinsic Functions: Yes (/Oi) Favor Size or Speed: Favor Fast Code (/Ot) Omit Frame Pointers: No Enable Fiber-safe Optimizations: No Whole Program Optimization: No What settings do you use? Has anyone had any good/bad experiences with these settings? Have you found any helpful blogs as to which settings to use?
Best wishes, Hans
In the kernel I like to turn them all off. That way you get exactly the code you wanted. I have had optimisations take out bits of code I intended to be in their (particulary dead loop timing stuff. Yes, the windows timer has NOT got a low enough granularity. :) You have to write tight code, no function calls in conditions in loops for example, but another benefit is that release code looks like your source, so it is easier to debug release build bugs.
============================== Nothing to say.
-
In the VS IDE (C/C++ Optimization), I usually set these optimizations for Release builds: Optimization: Maximize Speed (/O2) Inline Function Expansion: Any suitable (/Ob2) Enable Intrinsic Functions: Yes (/Oi) Favor Size or Speed: Favor Fast Code (/Ot) Omit Frame Pointers: No Enable Fiber-safe Optimizations: No Whole Program Optimization: No What settings do you use? Has anyone had any good/bad experiences with these settings? Have you found any helpful blogs as to which settings to use?
Best wishes, Hans
Optimization: Minimize Size Inline Function Expansion: Only those explicitly marked Enable Intrinsic Functions: Yes Favor Size or Speed: Favor small code Omit Frame Pointers: No Enable Fiber-safe Optimizations: Yes Whole Program Optimization: Yes Favour size or speed is a result of previous issues with speed optimizations causing problems. Also, smaller code can result in less page swapping, which swamps any benefits from 'faster' code. I had also done a compare of a number of apps compiled both ways. I was rarely able to find significant differences in speed, but often in size - the size opt had more effect. Inline expansion 'Any' has caused significant module bloating for me before. This usually happens with template code. I like this part to be deterministic. Fiber/whole optimizations, never had a reason to turn them off.
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
-
Mainly due to personal experience. I was trying to track down an intermittent crash that seemingly moved from one area of the app to another. A co-worker suggested removing /GL because it had caused him a similar problem. At this point I was grabbing for anything, so I removed /GL, and that was the last I saw of that crash. I wish I had a better justification, but I don't. There didn't seem to be any noticeable speed slowdown when /GL was removed, so I didn't pursue it.
Best wishes, Hans
I would suggest you save the PDB files generated by the compiler and also save the crash dump after the crash. You could then debug and get to the root cause of the crash.
«_Superman_» _I love work. It gives me something to do between weekends.
-
Optimization: Minimize Size Inline Function Expansion: Only those explicitly marked Enable Intrinsic Functions: Yes Favor Size or Speed: Favor small code Omit Frame Pointers: No Enable Fiber-safe Optimizations: Yes Whole Program Optimization: Yes Favour size or speed is a result of previous issues with speed optimizations causing problems. Also, smaller code can result in less page swapping, which swamps any benefits from 'faster' code. I had also done a compare of a number of apps compiled both ways. I was rarely able to find significant differences in speed, but often in size - the size opt had more effect. Inline expansion 'Any' has caused significant module bloating for me before. This usually happens with template code. I like this part to be deterministic. Fiber/whole optimizations, never had a reason to turn them off.
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
cmk wrote:
the size opt had more effect
I assume you mean the size opt yielded faster speed than the speed opt?
cmk wrote:
smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
What was the exe size in this case?
Best wishes, Hans
-
cmk wrote:
the size opt had more effect
I assume you mean the size opt yielded faster speed than the speed opt?
cmk wrote:
smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
What was the exe size in this case?
Best wishes, Hans
Hans Dietrich wrote:
What was the exe size in this case?
The total size of the executable is meaningless in relation to the favor small code optimization. What this does is favor optimizing each function/loop with a very small instruction count. Which may actually reduce the overall exectable size but thats not really the goal. The Favor fast code optimization optimizes for instruction execution throughput... and it may even make code larger because aligned instructions generally prefetch/execute faster. I don't want to give any specific numbers because I am not programming in asm as much these days and plus my expertise is mostly with the older Intel Pentium class processors. Some 32 bit generalizations that may still hold true: Favor small code: 1.) Could result in more branches but possibly fewer instructions. 2.) Makes an extra effort to keep functions/loops as small possible. 3.) May favor single-byte instructions utilizing the accumulator. 4.) May implement some jumps as sign-extended 8-bit shorts jumps resulting in smaller instruction size. Favor fast code: 1.) Attempts to keep unconditional branches to a minimum resulting in faster execution speed. 2.) May unroll loops resulting in higher instruction count. 3.) May attempt to align the loops to 16/32/64 byte blocks even at the cost of using more instructions. (Possibly even padding with NOPS!) Anyway what cmk is implying is that favor fast code will sometimes cause the function or loop to be much larger than a cache line resulting in slower execution and possibly a cache miss. All of the information I just gave you is speculative and relative to the older compiler code generation algorithms. Modern compilers such as VS2010 generate extremely efficient code in nearly all cases. I spent over a decade hand optimizing much of my C++ code sprinkled with with assembler and could nearly always optimize better than the MS compilers. Beginning with VS2005 I noticed that the compiler was optimizing equal or greater to what I could do by hand. To be perfectly honest... it doesn't make much of a difference these days. The Microsoft compiler is smart enough to know when it is generating inefficient code and sometimes will switch between fast/small code generation algorithms regardless of the engineers choice. The same goes for __inline and __forceinline where the compiler will completely ignore what the engineer wants in many cases. Btw, I would recommend that you start using whole progra
-
Hans Dietrich wrote:
What was the exe size in this case?
The total size of the executable is meaningless in relation to the favor small code optimization. What this does is favor optimizing each function/loop with a very small instruction count. Which may actually reduce the overall exectable size but thats not really the goal. The Favor fast code optimization optimizes for instruction execution throughput... and it may even make code larger because aligned instructions generally prefetch/execute faster. I don't want to give any specific numbers because I am not programming in asm as much these days and plus my expertise is mostly with the older Intel Pentium class processors. Some 32 bit generalizations that may still hold true: Favor small code: 1.) Could result in more branches but possibly fewer instructions. 2.) Makes an extra effort to keep functions/loops as small possible. 3.) May favor single-byte instructions utilizing the accumulator. 4.) May implement some jumps as sign-extended 8-bit shorts jumps resulting in smaller instruction size. Favor fast code: 1.) Attempts to keep unconditional branches to a minimum resulting in faster execution speed. 2.) May unroll loops resulting in higher instruction count. 3.) May attempt to align the loops to 16/32/64 byte blocks even at the cost of using more instructions. (Possibly even padding with NOPS!) Anyway what cmk is implying is that favor fast code will sometimes cause the function or loop to be much larger than a cache line resulting in slower execution and possibly a cache miss. All of the information I just gave you is speculative and relative to the older compiler code generation algorithms. Modern compilers such as VS2010 generate extremely efficient code in nearly all cases. I spent over a decade hand optimizing much of my C++ code sprinkled with with assembler and could nearly always optimize better than the MS compilers. Beginning with VS2005 I noticed that the compiler was optimizing equal or greater to what I could do by hand. To be perfectly honest... it doesn't make much of a difference these days. The Microsoft compiler is smart enough to know when it is generating inefficient code and sometimes will switch between fast/small code generation algorithms regardless of the engineers choice. The same goes for __inline and __forceinline where the compiler will completely ignore what the engineer wants in many cases. Btw, I would recommend that you start using whole progra
Good summary. As you mention, the fast code option can can cause a cache miss. Additionally, earlier versions at least, could result in enough bloat to create extra pages. Related code, that under 'small' sits in the same page, could be split into different pages under 'fast'. This can result in more page faults. The performance impact due to page faults can exceed the speed improvements made from 'fast'. So, based on past experience, and that these days the difference in optimization strategies is generally minor, I still use 'small'. I haven't experienced the compiler ignoring my inline settings yet, have to check that, thanks. The memset issue ... I ran into the same things years ago and found the following: http://msdn2.microsoft.com/en-us/library/ms972826.aspx[^]
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack