someone (someone@somewhere.com) on 2/5/09 wrote:
>
>According to this study half of SPECint2006 programs have
>average core working sets exceeding 16 MB and nearly 20%
>exceed 32 MB:

Oh, you need more memory than the caches have, but I really
doubt that SpecInt has become that sensitive to the
cache size. At some point the numbers were along the lines
of "max 10% improvement from tripling the cache".

So no, SpecInt2006 certainly won't fit in the cache,
but with a larger cache you do capture a hell of a lot
of it. Things have a lot of locality. From a cache size
standpoint, the interesting part is the momentary working
set.

>The maximum cache one core/thread can use is 6 MB in C2D,
>8 MB in i7, and 12 MB in Itanium.

Actually, the number I quoted for Itanium was for the
18MB L3 cache (does that make it 9M per core?). Why?

Because that's the highest performance result I found, due
most likely to the 1.66GHz (rather than 1.6GHz) sku.

That should already tell you something: it's not nearly
as cache sensitive as it is frequency-sensitive. The
smaller cache wins, just because it runs a tiny bit
faster.

Now, it's hard to do cache sensitivity analysis on the
SpecInt2006 numbers, exactly because there are different
frequencies, and they are submitted by different vendors
at different times. But go look, and you'll see that the
difference between the 18MB and 24MB sku's for the cases
when the same vendor reported numbers at the same time
are basically zero.

Of course, maybe the smaller-cache one had a worse memory
subsystem, and they just happened to cancel out, so it
proves nothing, but I think it's more likely that 16MB
cache is just "enough" that platform effects aren't that
big at least on SpecInt. Yes, even 2006.

(And obviously things change if you have much less cache.
The difference between 1MB and 2M is going to be quite big.
But when everybody involved has 8M+ of cache, what matters
most is how fast the cache is - at different levels -
and the core itself. Not so much the platform outside the
L3).

Linus