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

[Matt Mackall]

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.

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.

(Unfortunately, Zwane is an enemy of history and the URL for the
benchmarks he posted for out-of-line spinlock has gone stale.)

-- 
Mathematics is the supreme nostalgia of our time.
-
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/