And you could say the same thing about Itanium. (In fact, Gordon Bell did.)
The real problem was Intel's focus on frequency above all else at the time. They were demoing I think a 10 GHz processor at Intel Developer Forum at one point.
A few years later as the world had pretty much entirely shifted to multicore, a senior Intel exec I was doing some work for basically told me that of course they knew the challenges around ramping frequency. But Microsoft was apparently very concerned about the ability of Windows to use multiple cores.
There was a lot of concern in the industry at the time around how well software--especially on the desktop--would be able to take advantage of multiple cores.
I don't know if they demoed that or not, but I can remember early claims in the press that they expected the P4/Netburst architecture to scale to 10GHz.
They knew they couldn’t keep it up. But when you have a process advantage you want to maintain it. To put it another way, they wouldn’t be sacrificing and advantage to make multi core chips.
This is why I think intel parts are so power hungry, this pathological focus on single core perf.
That SB reintroduced netburst features doesn't change the history of the µarch. That's like saying Netburst not using a ROB means it was an evolution of Alpha rather than P6.
SB was not a renaissance of Netburst, it was a reintroduction, into the Core family, of features which Intel had first introduced in Netburst. Something which had already happened previously (e.g. hyperthreading in Nehalem) and would continue in the future (e. reintroduction of non-unified schedulers).
The "faults and sharp edges" of netburst were all caused by features which were at the core of netburst's identity, that's why it was a dead end and intel had to reset back to a sane working slate. As the article notes:
> Some of the fundamental ideas behind the architecture were definitely flawed.
And that Core was able to successfully integrate over time features first attempted in Netburst is exactly what you'd expect: many (though not all) of the individual features were not intrinsically bad and in fact several had been deployed successfully by other companies.
As the article specifically notes, the issues were introducing them all at once:
> Netburst debuted a mountain of new microarchitecture techniques. Some of these had been implemented by other companies, but were new to Intel. In general, the more you depart off the known path, the more risk you take. More changes mean more moving parts to tune and validate. Intel clearly took on way too much risk.
Especially in an architecture whose fundamental concepts and tradeoffs turned out to be unsound.