![]() | |||||||||||
Messages in this thread |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-01-04 06:55 [from the cache] ©2003-2008 | |||||||||||