4 ms·

Itanic was a flop due to AMD releasing 64bit CPU. And I still think Intel learned a lot from its failure if not from the technology but business-wise. Just stic

by _0w8t 4y ago

Itanic was a flop due to AMD releasing 64bit CPU. And I still think Intel learned a lot from its failure if not from the technology but business-wise. Just stick to improving the existing architecture while keeping backward-compatibility.

markhahn 4y ago
VLIW was really marooned in time: driven by overconfidence in the compiler (which had shown that you could actually expose pipeline hazards), and underestimates of the coming abundance of transistors (which make superscalar OoO really take off, along with giant onchip caches). well, and multicore to sop up even more available transistors.
- panick21_ 4y ago
  The problem is that VLIW has already proven not to work in the 90s with lots of companies investing money in it but not making it a product. EPIC was basically VLIW++ with lots of added stuff that should overcome the issues with it, but not doing that successfully. I don't think they underestimated the amount of transistors, they just thought that EPIC would be a better way to use them. OoO had already proven itself in the 90s as well, so its not like this was unknown when they designed EPIC.
  - kragen 4y ago
    otoh, for the previous 20 years, things like the 432 and lispms and burroughs large systems had been losing, in favor of architectures that pushed all the hard work onto compilers so it makes sense that in 01995 you'd look at ooo and vliw and extrapolate that vliw/epic was going to beat the crap out of ooo
    - panick21_ 4y ago
      Granted it makes some amount of sense. But the issue is that with EPIC you still can address every part of the processor unless you want to continue to grow the instruction. So you end up having to do OoO anyway but you just made it much more complex and hard to reason about. I'm not a chip designer but is what I understood to be one of the issues. Also if this compiler stuff wasn't jet written, unlike with RISC where people at Standford showed successful compilation for RISC already before people even developed any high performance RISC chips. I don't want to claim I'm smarter then those people, clear all the people working on these VLIW processor were a lot smarter then me. But then again many smart people worked on Alpha and they didn't go the VLIW route.
PAPPPmAc 4y ago
IMO, Itanic was a doomed design from the start, the lesson to be learned is that "You can't statically schedule dynamic behavior." The VLIW/EPIC type designs like Itanium require you have a _very clever_ compiler to schedule well enough to extract even a tiny fraction of theoretical performance for both instruction packing and memory scheduling reasons. That turns out to be extremely difficult in the best case, and in a dynamic environment (with things like interrupts, a multitasking OS, bus contention, DRAM refresh timing, etc.) it's basically impossible. Doing much of the micro-scheduling dynamically in the instruction decoder (see: all modern x86 parts that decompose x86 instructions into whatever it is they run internally that vendor generation) nearly always wins in practice. Intel spent decades trying to clean-room a user-visible high end architecture (iAPX432, then i860, then Itanium), while the x86 world found a cheat code for microprocessors with the dynamic translation of a standard ISA into whatever fancy modern core you run internally (microcode-on-top-of-a-RISC? Dynamic microcode? JIT instruction decoder? I don't think we really have a comprehensive name for it) thing. Arguably, NexGen were really the first to the trick in 1994, with their Nx586 design that later evolved into the AMD K6, but Intel's P6 - from which most i686 designs descend - is an even better implementation of the same trick less than a year later, and almost all subsequent designs work that way.
- pjmlp 4y ago
  Without AMD releasing AMD64, eventually WinIntel would be IA64 no matter what.
  - PAPPPmAc 4y ago
    Or Intel would have been cut out if they didn't put forth an offering that was less expensive and more performant? When NT4 came out, it ran on Alpha, MIPS, and PowerPC. You could even run (...at about half speed) x86 binaries on the Alpha port with FX!32. Apple has swung a transition like that twice, all the old Workstation vendors went from 68k to their bespoke RISCs, Microsoft could have just slowly transitioned out of Intel parts with no more difficulty than transitioning to IA64. Windows' PE format still doesn't have an elegant Fat binary setup (they have that Fatpack hack in windows-on-ARM, but it's worse than the 90s implementations), but that doesn't mean they couldn't have added one if compelled because the winning x86 successor(s) didn't end up being backward compatible. The biggest squeeze on 32 bit architectures is the memory ceiling, and Intel was doing PAE to get 36 bit addressing on the Pentium Pro in '95 and kept squeaking by with PAE well into the mid-2000s before most consumers cared. You only got 4GB per-process, and it took a couple years for chipset support to happen. The chipset issue is itself an interesting historical rabbit-hole, only one of the first-party chipsets for the Pentium Pro - the 450GX - which was a many-chip monstrosity, even _claimed_ to support more than 4GB of RAM. I've never found an example of a 450GX configuration with more than one 82453GX DRAM controller as indicated by the documentation to handle multiple 4GB banks to the extent that I suspect it may not have actually worked. By 96/97 there were 3rd party chipsets that could do >4 processors and >4GB, most prominently the Axil NX801 ( https://www.eetimes.com/axil-computer-to-incorporate-pentium-pro-processors-with-1-megabyte-cache-in-its-8-way-servers/ https://www.eetimes.com/axil-computer-to-incorporate-pentium... ) sold by DataGeneral as the AV8600 and HP as the HP NetServer LXr Pro8.
wtallis 4y ago
Based on https://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_edit.png https://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_e... it's clear that Itanium was delayed and sales projections were drastically reduced multiple times before AMD even announced their 64-bit alternative, let alone actually shipping Opteron. (For reference, AMD announced AMD64 in October 1999, published the spec August 2000, shipped hardware in April 2003. Intel didn't publicly confirm their plans to adopt x86-64 until February 2004, and shipped hardware in June 2004.)

by _0w8t 4y ago

markhahn 4y ago

VLIW was really marooned in time: driven by overconfidence in the compiler (which had shown that you could actually expose pipeline hazards), and underestimates of the coming abundance of transistors (which make superscalar OoO really take off, along with giant onchip caches). well, and multicore to sop up even more available transistors.

panick21_ 4y ago
The problem is that VLIW has already proven not to work in the 90s with lots of companies investing money in it but not making it a product. EPIC was basically VLIW++ with lots of added stuff that should overcome the issues with it, but not doing that successfully. I don't think they underestimated the amount of transistors, they just thought that EPIC would be a better way to use them. OoO had already proven itself in the 90s as well, so its not like this was unknown when they designed EPIC.
- kragen 4y ago
  otoh, for the previous 20 years, things like the 432 and lispms and burroughs large systems had been losing, in favor of architectures that pushed all the hard work onto compilers so it makes sense that in 01995 you'd look at ooo and vliw and extrapolate that vliw/epic was going to beat the crap out of ooo
  - panick21_ 4y ago
    Granted it makes some amount of sense. But the issue is that with EPIC you still can address every part of the processor unless you want to continue to grow the instruction. So you end up having to do OoO anyway but you just made it much more complex and hard to reason about. I'm not a chip designer but is what I understood to be one of the issues. Also if this compiler stuff wasn't jet written, unlike with RISC where people at Standford showed successful compilation for RISC already before people even developed any high performance RISC chips. I don't want to claim I'm smarter then those people, clear all the people working on these VLIW processor were a lot smarter then me. But then again many smart people worked on Alpha and they didn't go the VLIW route.

PAPPPmAc 4y ago

IMO, Itanic was a doomed design from the start, the lesson to be learned is that "You can't statically schedule dynamic behavior." The VLIW/EPIC type designs like Itanium require you have a _very clever_ compiler to schedule well enough to extract even a tiny fraction of theoretical performance for both instruction packing and memory scheduling reasons. That turns out to be extremely difficult in the best case, and in a dynamic environment (with things like interrupts, a multitasking OS, bus contention, DRAM refresh timing, etc.) it's basically impossible. Doing much of the micro-scheduling dynamically in the instruction decoder (see: all modern x86 parts that decompose x86 instructions into whatever it is they run internally that vendor generation) nearly always wins in practice. Intel spent decades trying to clean-room a user-visible high end architecture (iAPX432, then i860, then Itanium), while the x86 world found a cheat code for microprocessors with the dynamic translation of a standard ISA into whatever fancy modern core you run internally (microcode-on-top-of-a-RISC? Dynamic microcode? JIT instruction decoder? I don't think we really have a comprehensive name for it) thing. Arguably, NexGen were really the first to the trick in 1994, with their Nx586 design that later evolved into the AMD K6, but Intel's P6 - from which most i686 designs descend - is an even better implementation of the same trick less than a year later, and almost all subsequent designs work that way.

pjmlp 4y ago
Without AMD releasing AMD64, eventually WinIntel would be IA64 no matter what.
- PAPPPmAc 4y ago
  Or Intel would have been cut out if they didn't put forth an offering that was less expensive and more performant? When NT4 came out, it ran on Alpha, MIPS, and PowerPC. You could even run (...at about half speed) x86 binaries on the Alpha port with FX!32. Apple has swung a transition like that twice, all the old Workstation vendors went from 68k to their bespoke RISCs, Microsoft could have just slowly transitioned out of Intel parts with no more difficulty than transitioning to IA64. Windows' PE format still doesn't have an elegant Fat binary setup (they have that Fatpack hack in windows-on-ARM, but it's worse than the 90s implementations), but that doesn't mean they couldn't have added one if compelled because the winning x86 successor(s) didn't end up being backward compatible. The biggest squeeze on 32 bit architectures is the memory ceiling, and Intel was doing PAE to get 36 bit addressing on the Pentium Pro in '95 and kept squeaking by with PAE well into the mid-2000s before most consumers cared. You only got 4GB per-process, and it took a couple years for chipset support to happen. The chipset issue is itself an interesting historical rabbit-hole, only one of the first-party chipsets for the Pentium Pro - the 450GX - which was a many-chip monstrosity, even _claimed_ to support more than 4GB of RAM. I've never found an example of a 450GX configuration with more than one 82453GX DRAM controller as indicated by the documentation to handle multiple 4GB banks to the extent that I suspect it may not have actually worked. By 96/97 there were 3rd party chipsets that could do >4 processors and >4GB, most prominently the Axil NX801 ( https://www.eetimes.com/axil-computer-to-incorporate-pentium-pro-processors-with-1-megabyte-cache-in-its-8-way-servers/ https://www.eetimes.com/axil-computer-to-incorporate-pentium... ) sold by DataGeneral as the AV8600 and HP as the HP NetServer LXr Pro8.

wtallis 4y ago

Based on https://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_edit.png https://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_e... it's clear that Itanium was delayed and sales projections were drastically reduced multiple times before AMD even announced their 64-bit alternative, let alone actually shipping Opteron. (For reference, AMD announced AMD64 in October 1999, published the spec August 2000, shipped hardware in April 2003. Intel didn't publicly confirm their plans to adopt x86-64 until February 2004, and shipped hardware in June 2004.)