optimization defaults (was: Re: [GCC 3.0] Bad regression, binary size)

[Jonathan Thornburg <jthorn at galileo dot thp dot univie dot ac dot at>]

In message <URL:http://gcc.gnu.org/ml/gcc/2001-07/msg00617.html>,
Linus Torvalds <torvalds at transmeta dot com> wrote
> I would argue that floating point is a lot more special than kernels are.
> I bet the code generation and optimization issues for kernels tend to be
> closer to most programs than FP code tends to be. Which is why I think it
> is the FP code that should be special-cased, not the kernel.

In message <URL:http://gcc.gnu.org/ml/gcc/2001-07/msg01507.html>, I replied
| I'd like to put in a voice to urge that fp performance continue to be
| treated as "important".
| [[...]]
| So please, keep those fp-performance options (eg 16-byte stack alignment
| without having to always use a frame pointer on x86) alive for those of
| us who care!

In message <URL:http://gcc.gnu.org/ml/gcc/2001-07/msg01543.html>,
Linus Torvalds <torvalds at transmeta dot com> further commented
> I'm absolutely not arguing against you.
> 
> I would, for example, suspect that a "correct" optimization strategy for
> 99% of all real-world cases (not benchmarks) is:

I think your dichotomy between "real-world cases" and "benchmarks"
is mis-aimed, and that the dichotomy you're really focusing on here
is that between
(a) performance of long-running programs (whether integer or fp), for
    which there are plenty of well-regarded benchmark suites around,
    eg Quake framerates, SPEC2000{int,fp}, etc).
(b) startup time of various programs, either 'small' ones (ls, sh,
    perl, etc), or huge monsters like KDE, mozilla, staroffice, ...
    (there are benchmarks suites around for this kind of stuff, but
    they're not as popular as those for long-running programs)

gcc has historically offered various optimization options to help
tune (a)-performance, eg -O2, -O3 inlining, stack alignment, etc etc.

Linus seems to be objecting that by increasing code size and decreasing
locality, some of these (particularly loop unrolling, inlining, and
stack alignment) are likely to hurt (b)-startup-time.  This is a
reasonable enough concern... but the solution isn't to leave the
stack permantly unaligned and kill all gcc's other powerful
optimizations, it's to "just" not turn on the inappropriate
optimizations when compiling /bin/ls et al.


Quoting Linus Torvalds again
> - if it doesn't have floating point, optimize for the smallest size
>   possible. Never do loop unrolling or anything fancy like that.

(a) This is throwing out the baby with the bathwater -- it would
    seriously hurt performance on long-running non-fp programs that
    benefit substantially from loop unrolling.
(b) You can already get this behavior:  -Os  .


> Think of it this way: the single biggest slowdown that people react to
> badly on most machines is the initial loading time for a binary. There
> really aren't that many machines made today that "feel slow" from a CPU
> standpoint.

Once again, the word "most" begs the question of *which* people, on
*which* machines.  I agree with Linus that most machines today can fork
the fanciest shell around and exec /bin/ls in less than human reaction
time.  But try doing computer chess, or pcb routing, or for that matter
typing 'make bootstrap' in a gcc source tree, and you'll find plenty
of machines which "feel slow" even on purely integer programs (never
mind fp).


In some sense, I think the tension between Linus's concerns and mine
is irreconcilable, because he and I have very different workloads
(where we care about performance).

So perhaps the best solution might be to expand the semantics of  -Os
so it could influence things like how aggressive loop unrolling and
procedure inline should be, when to leave the stack misaligned, etc.
Perhaps  -Os  should have an (optional) integer argument, so -Os1
means a bit of space optimization, -Os2 more, -Os3 means really work
hard even at the expense of slow compilation, etc etc?

Then Linus could compile his OS kernels with -Os9, KDE and mozilla
could do the same, I could compile my black hole simulations with
-O9 -fomit-frame-ptr -finline-everything-in-sight -fstack-align=16,
and everyone would benefit.


In message <URL:http://gcc.gnu.org/ml/gcc/2001-07/msg01550.html>,
dewar at gnat dot com argued
> It is always tricky to argue about defaults. One critical issue with defaults
> is to make benchmarks work better out of the box, but the default of -O0
> seriously undermines this design criterion in any case.

I think we can safely assume that anyone doing benchmarks at -O0 is
clueless.  Maybe we want to add a sentence or two in the manual to
empasize that -O0 really means *no* optimization, but I don't think
we need worry about -O0 performance in anything except compile time.

-- 
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany             http://www.aei.mpg.de/~jthorn/home.html
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens