Compiler optimization for fastest possible code

Question

I would like to select the compiler optimizations to generate the fastest possible application.

Which of the following settings should I set to true?

• Dead store elimination
• Eliminate duplicate expressions within basic blocks and functions
• Enable loop induction variable and strength reduction
• Enable Pentium instruction scheduling
• Expand common intrinsic functions
• Optimize jumps
• Use register variables

There is also the option 'Generate the fastest possible code.', which I have obviously set to true. However, when I set this to true, all the above options are still set at false.

So I would like to know if any of the above options will speed up the application if I set them to true?

Answer 1

So I would like to know if any of the above options will speed up the application if I set them to true?

I know some will hate me for this, but nobody here can answer you truthfully. You have to try your program with and without them, and profile each build and see what the results are. Guess-work won't get anybody anywhere.

Compilers already do tons(!) of great optimization, with or without your permission. Your best bet is to write your code in a clean and organized matter, and worry about maintainability and extensibility. As I like to say: Code now, optimize later.

Answer 2

Don't micromanage down to the individual optimization. Compiler writers are very smart people - just turn them all on unless you see a specific need not to. Your time is better spent by optimizing your code (improve algorithmic complexity of your functions, etc) rather than fiddling with compiler options.

My other advice, use a different compiler. Intel has a great reputation as an optimizing compiler. VC and GCC of course are also great choices.

Answer 3

You could look at the generated code with different compiled options to see which is fastest, but I understand nowadays many people don't have experience doing this.

Therefore, it would be useful to profile the application. If there is an obvious portion requiring speed, add some code to execute it a thousand or ten million times and time it using utime() if it's available. The loop should run long enough that other processes running intermittently don't affect the result—ten to twenty seconds is a popular benchmark range. Or run multiple timing trials. Compile different test cases and run it to see what works best.

Spending an hour or two playing with optimization options will quickly reveal that most have minor effect. However, that same time spent thinking about the essence of the algorithm and making small changes (code removal is especially effective) can often vastly improve execution time.