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

Martin J. Bligh
2006-01-04T05:51:23Z

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.