Re: re:-O2 or -O3 ?

["brian (b.c.) white" <bcwhite@bnr.ca>]

>> I'm surprised that [-O3] make a 20% increase in code size, especially for
>> the probably negligible performance improvement.
>>
>> [...]
>> The bottom line is, unless your function is _very_ short (a few lines,
>> max, with no loops) in probably should _not_ be inline.  It sounds
>> like the GCC "heuristic" does just this, but it probably isn't as good
>> as a human could decide (with the "inline" directive).
>> 
>> I vote against using "-O3" and to stick with "-O2".
>
>We're building a distribution, so it makes sense to trade off
>computation at build time against computation at run time.

I agree with that.  The trade off I am against, in general, is
significant program size for insignificant program speed.

>I thought that the different -O<n> levels in GCC were different values
>of that tradeoff; if so, then we should be using the highest
>available.

True, but there is more...

Using the highest will make it run faster (usually), but also makes
the program size larger.  If inline functions make a program 20% larger and
only produces a 5% increase in speed, is it worth it?

>If the different -O<n> levels have some other general scheme I'd like
>to be enlightened as to what it is.

>From the GCC info page (v2.7.1)...
'-O'
'-O1'
     With `-O', the compiler tries to reduce code size and execution
     time.

`-O2'
     Optimize even more.  GNU CC performs nearly all supported
     optimizations that do not involve a space-speed tradeoff.  The
     compiler does not perform loop unrolling or function inlining when
     you specify `-O2'.  As compared to `-O', this option increases
     both compilation time and the performance of the generated code.

`-O3'
     Optimize yet more.  `-O3' turns on all optimizations specified by
     `-O2' and also turns on the `inline-functions' option.


Note that "-O2" is the highest form of optimization that does not trade
off space for speed.  Since Linux is sometimes run on machines with very
tight memory/disk constraints, then trading off significant space (>20%)
for insignificant speed (<10%) is, IMO, not worth it.  Measuring speed
improvement is, unfortunately, much more difficult than measuring program
size.

                                        Brian
                                 ( bcwhite@bnr.ca )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.