anon (no@no.no) on 8/14/09 wrote:
---------------------------
>Gabriele Svelto (gabriele.svelto@gmail.com) on 8/14/09 wrote:
>---------------------------
>>anon (no@no.no) on 8/13/09 wrote:
>>---------------------------
>>>A bit off-topic, but I wonder how high Intel would be able to clock Netburst if
>>>they had just kept shrinking it and improving it where necessary (IMC, better SIMD,
>>>etc). The last 65nm dual-core P4 had 3.6GHz and TDP 95W, and looking around it seems
>>>that overclocks to 4.4GHz were common.
>>
>>The latest stepping of 65nm P4 did have a 65W TDP actually and very low idle power.
>>Compared to the previous rounds of Prescotts they were decent desktop processors, but still not as good as the C2Ds.
>
>65W for single-core and 95W for dual-core, IIRC.
>
>
>>>I guess that a 32nm "P4" would reach 6.x GHz?
>>
>>Some people actually hit 8 Ghz with insance voltage and cooling proving that the
>>microarchitecture was designed with a significantly higher frequency target compared
>>to what did actually get on our desks. Though the performance benefits of such high
>>clocks are doubtful. As others pointed out K8 and C2D proved that IMCs, shorter
>>pipelines and seas of low-latency caches would be a much better road to follow.
>
>But couldn't IMC, better caches, better SIMD and other enhancements also be done to Netburst?
>I don't deny the merits of Core2 and i7 and I'm not really defending the P4, but
>if one says that i7 has 2x the IPC of Netburst but Netburst can have 2x the clock,
>then it seems that Intel could have kept improving netburst similarly to what AMD
>did to K7/K8/K10 if they really wanted.

Trying to improve on original Netburst is exactly what Intel's teams were busy with for years after Wmt, with one of their major efforts released commercially, at least one (tejas) canned in a very late stage, and at least one of the projects (original nehalem iirc) getting an axe relatively early in the project.

I wasn't there, this and other info is from folks who were involved, and if anyone can correct or add more, great then. It was not *just* about power issues; even original wmt uarch got way too complicated and an extreme pain to design and debug, so *improving* netburst could have easily become a harder goal than taking a P6 derivative as a starting point to work from or starting from scratch.

I personally am of opinion that the way netburst ended up is not because of specifically high clock per se (after all, IIRC K8 was commercially released at 2.6 GHz in 0.13 um -- ~.74 of NW's highest commercial clock), I think it has way more to do with the way work was organized at Intel (esp. how it was morphing over the 90s) and project leadership.

Not to be set as an overriding project goal of course, clock rate *is* important. It's not just about ALU ops being faster (although this alone can be a significant factor), higher clock provides you with finer temporal granularity so anything multicycle can either be tuned better or potentially lose less in unused portion of cycle time. Sure, it's not all gains and for one, design for high clock is far less tolerant of lack of expertise.