lkml.org 
[lkml]   [2006]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
 > ...
> 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.
-
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-05 02:01    [W:0.630 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site