how different would things have turned out?
Intel surely would have introduced 64-bit at some point . . . right?
They would have had do. Consumer software would not have put up with PAE (we had enough of that crap with 64K windows in DOS, thankyouverymuch), and IA64 was
not going to cut it. Intel could very well have screwed themselves over big time if AMD had not been competitive. It's not just that MS and AMD agreed about x86_64, but that their solution to 64-bit was a good one, and also satisfied the rest of the x86 universe, including Linux and Unixes.
Basically,
1. how much longer would we have had to wait for 64-bit on the consumer side
I would guess until 4-8GB was affordable (2007-8), because Intel wanted to push IA64, which nobody with any common sense wanted. That assumes, however, that (a) AMD died or gave up on x86, and (b) no one else would try to pick up the shiny pot of gold in the middle of the room that was IA32.
2. how different would Intel's instruction set have been? Would there have been any tangible benefits (cleaner, easier to compile against, better performance)? Were there any major deficiencies in AMD's instruction set because they weren't as good as Intel/were rushed/etc?
Good question. Hard to answer, without knowing what Intel had been cooking up. If Intel had, even w/o AMD competing, realized their hubris was harming them, they would have come up with something other than IA64, and likely had something else in the works, anyway.
My guess is Nehalem would have been IA64 leaving Penryn/Wolfdale as the legacy x86 CPU to compete with AMD. AMD would get MS to remove the 4GB limit in Vista/7 then try to convince the world that x86+
AWE>IA64 until the 09 settlement which AMD would get a IA64 license then we would be wondering today if AMD's upcoming IA64 CPU would make them competive again. Someone at HP would been like we could've taken x86's spot during that transistion if we hadn't killed Alpha.
There's just two problems with that: Itanium and Opteron.
- Too many registers: check. Too many registers will make renaming effectively difficult. Register renaming has been an excellent performance-enhancing feature, making good use of small register sets, since 1967. Not only that, but you usually don't even need more than IA32's <=4 GPRs, and x86_64's added GPRs take care of
almost every case but hot software-unrollable computing loops.
- Software MMU: check. Software page walks are slow, and way too much code is spent doing what the HW should be doing, instead. ALpha had this, too, but Alpha had enough good things going for it to make up for it.
- Absurdly large code: check. Bigger code means worse I$ performance, all else being equal; and making a bigger I$ increases penalties from cache misses.
- Software scheduling of in-order pipelined superscalar execution: check. Software scheduling makes even bigger code, with one or more profile-guided paths for decent performance (not much software out there on PCs and servers gets PGO, unless the performance is unpredictably bad), and necessarily will create more and longer stalls in branch-filled code than will fully hardware branch prediction and OOOE, because to handle all combinations of currently-available data, you need ever-more distinct code paths. Hardware data prefetching was also just starting to get good enough around the time IA64 was in the works, which compliments OOOE quite well.
VLIW should stay far away from general purpose CPUs. IA64 isn't VLIW in a strict sense, but the software scheduling and instruction bundling give it enough bad features of VLIW to lump it in with more pure VLIW.
- Poor IA32 performance. Itaniums have not had good IA32 performance, and that performance matters thousands of times more than the native performance, even today. You think they could have made a quad core x86 coprocessor that used less power than SB, getting similar IA32 performance, and still had enough physical room and TDP left over for IA64? I doubt it.
The reason IA64 didn't completely fail is that HP supported it, and it only. So, if you ran Alpha, PA-RISC, used Tandem stuff, etc., you needed to either move to Itanium, or start over from scratch, if you ever needed to upgrade. IA64 would cause nothing but consumer backlash. Even today, IA32 performance matters. Why would you want a new ISA who's chips perform poorly w/o PGO, and who's x86 performance sucks? Screw that. Big bad Itanium server CPUs
still have bad performance.
- Finally, why would Intel have brought out the Pentium-M, made the Core, the Core 2, Nehalem, and so on,
if there had never been an Opteron? We wouldn't even
have Nehalem. We don't even know if Intel would have gotten a fire lit under their asses, instead of trying to push more Netburst and IA64. The K8 was probably the best thing that could have happened to Intel in the early 00s.
We could have moved to ARM, MIPS, PPC, etc., and as long as there was good JIT x86 support in firmware, been alright. If Intel had sufficiently pushed IA64, we likely would have. A nice 64-bit PPC with JIT x86 that could run at least 2/3 the speed of native code, FI, would have easily beaten out Itanium-like desktop chips, and further Netburst derivatives (not unreasonable, especially if the ISA got extensions for JIT in general, or for x86-specific features that were slow when made into PPC).
