Hacker News Reader

Comment by hedgehog | Hacker News Reader

It's unclear to me what would have likely happened had AMD stayed on IA32 and Netburst been uncontested. Itanium was far too expensive for consumer machines and it seems very possible that Intel would have fumbled IA64 in a way similar to more recent AVX-512 and their big.little efforts. Easy enough to port XP to Itanium, hard to get those machines into Best Buy or the Dell catalog in any way that makes sense. Had AMD continued Athlon performance improvements and Intel still responded with a P6-derived Pentium M (which even in our timeline was 32-bit) it still seems like there would have been no volume market for IA64 and we still would have eventually ended up with an evolution of IA32 even if it came from Intel instead of AMD.

View on HN

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.

Reply on news.ycombinator.com