[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: re:-O2 or -O3 ?

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

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)...
     With `-O', the compiler tries to reduce code size and execution

     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.

     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

                                 ( bcwhite@bnr.ca )

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

Reply to: