Bill Todd (billtodd@metrocast.net) on 6/19/03 wrote:
---------------------------
>Paul DeMone (pdemone@igs.net) on 6/19/03 wrote:
>---------------------------
>>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.
>
>So if I managed to get past all that gushing appreciation

"remarkably scalable memory hierarchy" is gushing?

Coming from Mr. Itanic that seems the height of hypocrasy.

>to the heart of the matter,
>it sounds as if your analysis predicts a SPECint_base score for the 1.5 GHz Madison
>of something like 1175 (assuming unchanged compiler technology).

Sounds reasonable although I would be surprised if IPF compilers haven't improved
since HP's 810 SPECint_base2k score was submitted.

The 1175 figure is ahead of both Opteron and POWER4+. All three MPUs likely
have some clock scaling left to do in 130 nm so it will be interesting to see who
is ahead at the end of it. A remarkable turn around for an aspect of IPF processor
performance thought to be its achilles heal. Not that it is all that important for the
market IPF targets as Sun clearly showed before the dot com bust.

> I just keep thinking
>back to Arcadian's glowing assurances that Madison would beat the bejazus out of
>Opteron and wondering if it can really be that low.

Did he say this with reference to SPECint2k or did you *assume* this. We all
know how badly you act up when you think others rashly *assume* things.
Again another instance of your remarkable capacity for hypocrasy.

Curious you didn't bother with a SPECfp2k estimate for a 1.5 GHz Madison.
What's your estimate Bill? How does that compare to Opteron and POWER4+?