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

Martin Bligh
2006-01-05T00:58:27Z

> ...
> 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.