It is all what ifs by now, however I firmly believe if there was no other option other than Wintel, Intel would keep pushing Itanium and sort out the design issues.
The thing with AMD64 is that now there is this myth that there was no other alternative than keeping up with x86, and Itanium redesigns for some magical reason were impossible.
Other than those redesigns never happened, because AMD64 made economic invalid to pursue them.
Itanium has well over a kilobyte of general-purpose registers. That's lovely for single-process performance, but it absolutely slaughtered context switch time given the available memory bandwidth at the time. On top of that, it was fiendishly difficult to actually find instructions that could fill the instruction stream, and thus i-cache utilization was a disaster. On top of all of that, it exposed far too much microarchitecture to userspace: it would forever be pinned to having three execution ports with very specific capabilities, and any changes to the µarch would have resulted in all of the complicated register rename and instruction scheduling hardware that VLIW was supposed to avoid.
I'll grant that it seemed like a decent idea at the time, but there was enough risk there that I can only describe Intel's all-in stance on Itanium to have been a blunder.
(There's a worthwhile distinction to be made between a blunder and a mistake. Mistakes are calculated risks that don't pan out, whereas a blunders is something that should have been obvious that it would go poorly when the decision was made. Losing your savings in the stock market from a surprise dip is a mistake. Losing your savings by betting it all on 14 in Vegas is a blunder. Similarly, the design of Itanium was a mistake. Betting the company on it was a blunder.)
As pjmlp points out we don't know what would have happened if Intel had spent another few billion dollars re-implementing IA64 in a lower cost / lower power form. To me one of the big lessons of the last few decades is that pragmatic microarch has convergent evolution due to the same underlying constraints of expensive memory access, clock speed scaling limits, general non-determinism of everything surrounding the core, etc, and within reason the ISA will end up conformed to those limits in a way that makes the initial ideology (RISC, CISC, VLIW) not so important. For example RISC is simple, except once you mix OoO, compressed instructions, macro op fusion, etc, those all have externally visible effects so c'est la vie simplicity.
One can imagine an evolution of IA64 that conceded microarchitectural complexity to allow adoption of a more compact instruction format with dependency tags rather than fixed bundle width, resulting in something more like an evolution of P6 with a different face, better x86 compatibility, and still ISA uniformity with the big iron. Or an evolution that involved buying Transmeta and adding IA64 support to that.
Obviously Intel didn't end up doing any of these things, probably because distribution strength and process superiority allowed them to do less and still post strong quarterly numbers. I'm not even sure if it was a blunder given the local incentives of the people who worked there at the time.
Comments
It is all what ifs by now, however I firmly believe if there was no other option other than Wintel, Intel would keep pushing Itanium and sort out the design issues.
The thing with AMD64 is that now there is this myth that there was no other alternative than keeping up with x86, and Itanium redesigns for some magical reason were impossible.
Other than those redesigns never happened, because AMD64 made economic invalid to pursue them.
Itanium has well over a kilobyte of general-purpose registers. That's lovely for single-process performance, but it absolutely slaughtered context switch time given the available memory bandwidth at the time. On top of that, it was fiendishly difficult to actually find instructions that could fill the instruction stream, and thus i-cache utilization was a disaster. On top of all of that, it exposed far too much microarchitecture to userspace: it would forever be pinned to having three execution ports with very specific capabilities, and any changes to the µarch would have resulted in all of the complicated register rename and instruction scheduling hardware that VLIW was supposed to avoid.
I'll grant that it seemed like a decent idea at the time, but there was enough risk there that I can only describe Intel's all-in stance on Itanium to have been a blunder.
(There's a worthwhile distinction to be made between a blunder and a mistake. Mistakes are calculated risks that don't pan out, whereas a blunders is something that should have been obvious that it would go poorly when the decision was made. Losing your savings in the stock market from a surprise dip is a mistake. Losing your savings by betting it all on 14 in Vegas is a blunder. Similarly, the design of Itanium was a mistake. Betting the company on it was a blunder.)
As pjmlp points out we don't know what would have happened if Intel had spent another few billion dollars re-implementing IA64 in a lower cost / lower power form. To me one of the big lessons of the last few decades is that pragmatic microarch has convergent evolution due to the same underlying constraints of expensive memory access, clock speed scaling limits, general non-determinism of everything surrounding the core, etc, and within reason the ISA will end up conformed to those limits in a way that makes the initial ideology (RISC, CISC, VLIW) not so important. For example RISC is simple, except once you mix OoO, compressed instructions, macro op fusion, etc, those all have externally visible effects so c'est la vie simplicity.
One can imagine an evolution of IA64 that conceded microarchitectural complexity to allow adoption of a more compact instruction format with dependency tags rather than fixed bundle width, resulting in something more like an evolution of P6 with a different face, better x86 compatibility, and still ISA uniformity with the big iron. Or an evolution that involved buying Transmeta and adding IA64 support to that.
Obviously Intel didn't end up doing any of these things, probably because distribution strength and process superiority allowed them to do less and still post strong quarterly numbers. I'm not even sure if it was a blunder given the local incentives of the people who worked there at the time.