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

[Martin Bligh <mbligh@google.com>]

 > ...
> But even then it's actually really hard to measure. Cache effects tend to 
> be hard _anyway_ to measure, it's really hard when the interesting case is 
> the cold-cache case and can't even do simple microbenchmarks that repeat a 
> million times to get stable results.
> 
> So the best we can usually do is "microbenchmarks don't show any 
> noticeable _worse_ behaviour, and code size went down by 10%".

OK, that makes a lot of sense to me. It was just worrying that nobody 
seemed to be measuring performance _at all_, just talking about code 
size, which is all very nice, but not really an end goal (for most 
systems). It seems to me like a simple tradeoff - cycles vs cache 
misses, and people seem to be only looking at one side.

I wasn't trying to say it was bad ... just seemed insufficently 
justified to me (at least regression tested, as you say).

> So at a total guess, and taking the above numbers (that are questionable, 
> but hey, they should be ok as a starting point for WAGging), reducing code 
> size by 10% should give about 0.007 cycles per instruction in user space. 
> Whee. Not very noticeable. But on system code (the only thing the kernel 
> can help), it's actually a much more visible 0.05 CPI.
> 
> Yeah, the math is bogus, the numbers may be irrelevant, but it does show 
> why I$ should matter, even though it's much harder to measure.

The IBM PPC people had some fancy way of measuring CPI and were very 
interested in it. Perhaps we can taunt them into helping measure things.

M.