Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Matt Mackall <mpm@selenic.com>]

On Tue, Jan 03, 2006 at 09:51:17PM -0800, Martin J. Bligh wrote:
> Matt Mackall wrote:
> 
> >On Tue, Jan 03, 2006 at 03:40:59PM -0800, Martin J. Bligh wrote:
> > 
> >
> >>It seems odd to me that we're doing this by second-hand effect on
> >>code size ... the objective of making the code smaller is to make it
> >>run faster, right? So ... howcome there are no benchmark results
> >>for this?
> >>   
> >>
> >
> >Because it's extremely hard to design a benchmark that will show a
> >significant change one way or the other for single kernel functions
> >that doesn't also make said functions unusually cache-hot. And part of
> >the presumed advantage of uninlining is that it leaves icache room for
> >random other code that you're _not_ benchmarking.
> >
> >In other words, if it's not a microbenchmark, it generally can't be
> >measured, directly or indirectly. And if it is a microbenchmark, the
> >result is known to be biased.
> > 
> >
> Well, it's not just one function, is it? It'd seem that if you unlined
> a whole bunch of stuff (according to this theory) then normal
> macro-benchmarks would go faster? Otherwise it's all just rather
> theoretical, is it not?

Yes, if we uninline a big hunk of stuff, we should see results. But
which hunk? Running benchmarks w/ and w/o Ingo's 3 patches should be
educational. As would with -Os.

Also note that there are going to be cases where smaller wins by
orders of magnitude: where it makes the difference between the working
set fitting in cache or RAM or not.
 
> Cool, that sounds good. How much are we talking about?
> I didn't see that in the thread anywhere ... perhaps I just
> missed it, sorry it got long ;-)

The out of line spinlock stuff went by about a year ago. Google for
"zwane spinlock out of line".

-- 
Mathematics is the supreme nostalgia of our time.