Paul DeMone (pdemone@igs.net) on 6/20/03 wrote:
---------------------------
>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+?

sigh... actually i don't think Bill is being hyprocritical. I think he is being a bit polarized in his views, but not hyprocritical. That he conceded a point, even if in a way that put the better light to his concesion is neither hyprocritical nor is it disingenous. It is lamentable to me that IPF will succede in making Opteron possibly a non starter in the market that AMD wanted to invade. I personaly find the IPF idea a little.. ahead of its time.
I think I mentioned before that I felt the IPF was the flying wing of the silicon universe. I think that while Intel has managed to clear the field as much as possible as far as competition is concerned with Itanium and I2, there still, I think is a valid concern about the real cost effectiveness with regards of this implementation of the whole idea vs its performance. I think that many of the technologies needed to make it a resounding success are not yet fully developed, just like the flying wing needed to wait for certain control techs to come about to make it fully marketable.
Problem i continue to see is that there are TWO technology tracks that need to be done correctly to get this silicon working to its full potential. One is the hardware and the other is the compiler (ie software). THEN in addition you have to get all the ISV's into line. In this regard the K8 does have a certain advantage, since it realy only needs the hardware to be developed agressavily, even if the 64bit stuff remains half assed. This of course is depedent on the k8 being able to realy bring good performance on 32 bit code.

It should remain an interesting proposition to see if the economy of scale applies not only to the hardware but also to the software with regards to IPF.

Marc M.