Bill Todd (billtodd@metrocast.net) on 6/19/03 wrote:
---------------------------

>One more interesting tidbit that I noticed in that presentation was the L3 latency
>of 14 clock cycles. My recollection is that McKinley's L3 latency was 12 cycles
>(though it may have been more in some situations - ISTR the range 12 - 15 cycles
>being mentioned once): does this indicate a slightly sub-linear improvement in
>L3 performance for Madison?

I found an old spreadsheet in which I modeled the Merced and McKInley cache
and memory hierarchies. The representative figure for average memory access
for a SPECint style workload for a 1 GHz McKinley was 2.34 cycles.

If you simply increase clock rate to 1.5 GHz this figure increases to 2.82 cycles.
Increasing L3 latency from 12 to 14 cycles increases this to 2.84 cycles. Now
if you reduce the L3 global miss rate by 29% to account for the capacity doubling
to 6 MB using the inverse square root rule of thumb then average memory latency
falls back to 2.42, a bit more than the McKinley figure we started with. Extending
that to the reported Madison+ (1.8 GHz, 9 MB) and the latency falls to 2.40 cycles.
And if the Madison+'s 9 MB L3 latency goes up another 2 cycles, to 16, we stay
at 2.42 cycles. All in all a remarkably scalable memory hierarchy that preserves
the system level infrastructure (a 1.8 GHz Madison+ will generate roughly the
same level of memory traffic as a 1 GHz McKinley yet yield perhaps 70% or
more higher performance on most CPU intensive workloads).

The specific numbers will vary from code to code of course but I think it is clear
that the increase in L3 latency is completely negligible compared to CPU clock/
memory access time scaling mismatch. And that in turn isn't a big issue since
another analysis I did based on published I2 CPI breakdown data for SPEC CPU
2k suggested McKinley's performance scaling factors were calculated at above
90% for both SPECInt and SPECfp and actually improved for Madison despite its
higher clock rate.