Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds <torvalds at transmeta dot com>]

In article <200107231146.NAA11586@mach.thp.univie.ac.at> you write:
>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.
>
>I think this is a fundamental philosophical point... with which I
>strongly disagree.  The problem is that referring to "most" programs
>begs the question of just which sort of workload you're sampling.
>
>I'd like to put in a voice to urge that fp performance continue to be
>treated as "important".  Indeed, the integer programs that _I_ use
>(including OS kernels, shells, web browsers, not to mention gcc itself)
>are generally either not CPU-bound, or are already "fast enough", so
>I really don't care very much about integer performance.  But the fp
>codes I develop and use for a living are all painfully slow, and the
>science I'm doing with them would be a lot better if they were faster,
>so I care a lot about fp performance.

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:

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

 - if it has floating point or MMX, go wild at that point.

(And make the "has floating point" decision something more clever than
just "oh, I saw a fp reg here").

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

My argument is really the same, but with a twist: keep it alive, but
don't make it the default if it makes non-FP code bigger.

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.

Which means that loop optimizations seldom make sense for most things. 
Most integer workloads have fairly low repeat-rates: we're talking
hundreds or maybe few thousand repeats of most loops.  You have to make
those loops a heck of a lot faster to make up for a single page-fault
brought on by making the code larger.  Even just a single icache miss
(and you're pretty much _guaranteed_ an icache miss on program startup)
tends to be enough to the advantage of a win of a cycle or two. 

Most programs have become _less_ loopy, and the loops have grown much
bigger. 

The exception is FP and vector-integer stuff (MMX, AltiVec, whatever you
call it). 

		Linus