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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
