>Linus Torvalds (torvalds@linux-foundation.org) on 8/13/09 >wrote:
>You do realize that Core 2 (and especially Nehalem) gets
>almost twice the IPC of P4 on a lot of real-world loads?
>
>So that hypothetical 6.x GHz Netburst often wouldn't then
>actually be any faster than the chips you can buy today.

The original Core 2 didn't. It took many iterations and not just core architectural enhancements but improvements on the memory interface and cache structure to get today's Nehalem's IPC this high compared to the last Netburst iteration. Given how memory starved Netburst was, there's a lot of reason to believe the IMC alone would make a 6GHz part comparable (depending on workload of course) to a modern Core 2.

>Now, it's possible that they could have improved the P4
>microarchitecture in some magical way, but it's unlikely.
>A lot of the fundamental improvements in Nehalem were all
>about being clever, and doing things that you almost
>certainly would not have been able to do in the P4 kind
>of pipeline (ie all the clever memory reordering etc).

To be quite honest, I doubt any of that is significant compared to the performance increase of having an IMC, which is perfectly suitable for Netburst.

>So even a very highly clocked P4 really isn't all that
>interesting. You'd need more than twice the frequency
>head-room for P4 to look good.

I wouldn't say so. There was a lot of room for improvement with the last P4 iteration, many of which went into Nehalem. The branch predictor was a simple single-layer perception I believe vs the local/global multi-level perceptron used in Nehalem. The cache on the last P4 is nowhere near as fast, dense nor low-latency as that on Netburst, not to mention, once again, the IMC. Saying Nehalem -- with all of that -- performs at twice the IPC of the last Netburst iteration (which was what, 3 years ago? 4?) is kind of disingenuous.

One of the problems with a Netburst type design is that process shrink does not guarantee frequency scaling the way we saw from 350 down to 90 anymore. A 32nm part won't be scaling to extremely high frequencies even with the short pipeline stages.

Then there's the big elephant in the room: power. The power-gating, clock-gating, fine-granular voltage and frequency scaling features of a Nehalem design simply is not easy and/or impossible to design into parts that function at 6 GHz. Your IDDQ would make it more of a power drain to turn parts on and off vs just leaving them on all the time.