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

[Martin J. Bligh]

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?

> In the rare case of functions that are extremely popular (like
> spinlock and friends), we _can_ actually see small improvements in
> macrobenchmarks like kernel compiles. So it's fairly reasonable to
> assume that reducing icache footprint really does matter more than
> cycle count and extrapolate that to other functions.
>  
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 ;-)

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/