5 ms·

The worst thing about Itanium is that it killed DEC Alpha, high-performance MIPS and some other arches I keep forgetting about.

GrilledChips 3y ago
It's kind of funny. There are lots of architectures it killed (Alpha, PA-RISC, basically everything except SPARC because Sun was sceptical) but basically all of them have outlived it in the linux kernel. It killed their manufacturing based on hype, where as they all established a firm install base before itanium ever got rolling, which has ensured they continue to be (halfheartedly) maintained.
- cbmuser 3y ago
  Itanium was killed because unlike all the other architectures it puts a rather big burden on upstream developers due its complicated design (dual stack with growth into two directions, complicated compiler optimizations etc).
  - usrusr 3y ago
    I keep wondering if it perhaps simply appeared too early. These days it feels as if almost everything is either open source or runs in some form of JIT compile VM, or both. Back then it was a huge problem to require code to be compiled not just to the general architecture but to the specific model to be fast. But today? Moving some of the adaptions from the hardware scheduler to process lifetime persistence (as in JIT VM) or even into the software distribution infrastructure could be delightfully transparent.
    - vgatherps 3y ago
      It would probably be even worse today. Dynamically discovering ILP “just works” even as memory gets slower and slower and slower. A CPU today can execute hundreds of instructions and many predicted branches ahead of a slow load. It would be impossible to statically schedule this (you don’t know what will/won’t be in cache), and difficult to try and hoist all loads 100 instructions in advance especially when you take branching behavior into account. GPUs have taken over much of the niche where these processors excel, number crunching where you have entirely pre-determined memory / compute access patterns.
      - anarazel 3y ago
        For GPUs it only really works because the code is translated to the relevant instruction steam close to the time of executing, where you can afford to optimize in a highly uarch specific way. Whereas VLIW at the time of itanium never was in that position... It just doesn't compute for me how Intel thought this was a good plan. It's not like they didn't know that existing compiled binaries are going to continue being used on newer uarchs
        p_l 3y ago
        The critical part was less VLIW, and more EPIC - the Explicit Parallel part. There were previous VLIW arches that didn't have issues with compilers, one of them afaik even formed backbone of many advanced optimizing compilers in 1990s because the vendor licensed the compiler tech to others.
        deleted 3y ago
        [deleted]
voidfunc 3y ago
In some ways that has been the biggest win for Intel... product flopped but we also killed 90% of our competitors is an amazing outcome.
inopinatus 3y ago
In contributing to the death of the Alpha it also ensured the decline of Tru64 Unix and thereby stalled the development of AdvFS, which I definitely mourn.
- matja 3y ago
  It lives on in spirit, having heavily influenced the design of ZFS and its admin interface: advfs addvol -> zpool add advfs advscan -> zpool import advfs clonefset -> zpool clone advfs mkfset -> zfs create advfs rvdump -> zfs send advfs rvrestore -> zfs receive advfs showfsets -> zfs get/list advfs verify -> zpool scrub
chasil 3y ago
While it might sound contrarian, Alpha actually deserved to die. It guzzled power. This was the biggest problem, not solvable in its lifetime with its resources. "According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible." https://en.m.wikipedia.org/wiki/StrongARM https://en.m.wikipedia.org/wiki/StrongARM
- djbusby 3y ago
  Back in the NT4 days, which supported Alpha, my lab had a few of their boxes. Dual 500Mhz (it was ~1998) Huge box with a huge PSU. And we had some cheapo desktop HPs with dual Pentium2(3? (the card edge ones)) at like 450 or 533. Which basically ran circles and sipped power by comparison. Don't remember the exact numbers but only 2 per 15A circuit; with 4 of the x86 per.
- akuma73 3y ago
  A lot of ex-Alpha engineers went to PA-Semi which Apple then acquired. Those people are responsible for the epic custom Apple ARM CPUs.
  - chasil 3y ago
    Like I said, DEC also did StrongARM, which probably gave designers in many areas a new perspective.
  - deaddodo 3y ago
    A lot of the Alpha engineers (including Keller) went to AMD and made the Athlon. The Athlon (K7/K8, specifically) was/is considered the spiritual successor to the 21264, by many. But yeah, many ended up looping around to PA Semi (again, including Keller).
pengaru 3y ago
Jim Keller has stated in at least one talk that DEC went bankrupt after Windows NT on Alpha kept crashing because they'd designed the Alpha with weak memory ordering and MS wouldn't implement the necessary memory barriers. Didn't sound like Itanic played a part at all.
- p_l 3y ago
  Itanic played part after Compaq buyout, where Compaq decided to bank all on Itanium sight unseen of actual usable parts, IIRC. The end result was that they had to restart development of EV7 then restart its production again, because many, many ex-DEC customers didn't want to move to Itanium (customers running Tru64 mostly moved to Linux on amd64 or occasionally to other RISC vendors instead of dealing with HP-UX, whereas OpenVMS customers kept to Alphas which outperformed Itanium usually or moved off the platform completely, with stragglers now moving to amd64)
  - javitron 3y ago
    Alpha was on life support by the time Compaq bought DEC. AXP was literally one of the things that basically killed DEC. By the time HP bought Compaq, AXP was on legacy mode. Plus Itanium was as much of an HP architecture as it was intel's, so it made no sense for HP to develop AXP further.
javitron 3y ago
What killed Alpha and high performance MIPS (And eventually SPARC) was simple economics; their design costs grew faster than the revenue they generated. I don't think many of the arm chair CPU experts really understand how expensive it is to design a high performance CPU core.

GrilledChips 3y ago

It's kind of funny. There are lots of architectures it killed (Alpha, PA-RISC, basically everything except SPARC because Sun was sceptical) but basically all of them have outlived it in the linux kernel. It killed their manufacturing based on hype, where as they all established a firm install base before itanium ever got rolling, which has ensured they continue to be (halfheartedly) maintained.

cbmuser 3y ago
Itanium was killed because unlike all the other architectures it puts a rather big burden on upstream developers due its complicated design (dual stack with growth into two directions, complicated compiler optimizations etc).
- usrusr 3y ago
  I keep wondering if it perhaps simply appeared too early. These days it feels as if almost everything is either open source or runs in some form of JIT compile VM, or both. Back then it was a huge problem to require code to be compiled not just to the general architecture but to the specific model to be fast. But today? Moving some of the adaptions from the hardware scheduler to process lifetime persistence (as in JIT VM) or even into the software distribution infrastructure could be delightfully transparent.
  - vgatherps 3y ago
    It would probably be even worse today. Dynamically discovering ILP “just works” even as memory gets slower and slower and slower. A CPU today can execute hundreds of instructions and many predicted branches ahead of a slow load. It would be impossible to statically schedule this (you don’t know what will/won’t be in cache), and difficult to try and hoist all loads 100 instructions in advance especially when you take branching behavior into account. GPUs have taken over much of the niche where these processors excel, number crunching where you have entirely pre-determined memory / compute access patterns.
    - anarazel 3y ago
      For GPUs it only really works because the code is translated to the relevant instruction steam close to the time of executing, where you can afford to optimize in a highly uarch specific way. Whereas VLIW at the time of itanium never was in that position... It just doesn't compute for me how Intel thought this was a good plan. It's not like they didn't know that existing compiled binaries are going to continue being used on newer uarchs
      - p_l 3y ago
        The critical part was less VLIW, and more EPIC - the Explicit Parallel part. There were previous VLIW arches that didn't have issues with compilers, one of them afaik even formed backbone of many advanced optimizing compilers in 1990s because the vendor licensed the compiler tech to others.
        deleted 3y ago
        [deleted]

voidfunc 3y ago

In some ways that has been the biggest win for Intel... product flopped but we also killed 90% of our competitors is an amazing outcome.

inopinatus 3y ago

In contributing to the death of the Alpha it also ensured the decline of Tru64 Unix and thereby stalled the development of AdvFS, which I definitely mourn.

matja 3y ago
It lives on in spirit, having heavily influenced the design of ZFS and its admin interface: advfs addvol -> zpool add advfs advscan -> zpool import advfs clonefset -> zpool clone advfs mkfset -> zfs create advfs rvdump -> zfs send advfs rvrestore -> zfs receive advfs showfsets -> zfs get/list advfs verify -> zpool scrub

chasil 3y ago

While it might sound contrarian, Alpha actually deserved to die. It guzzled power. This was the biggest problem, not solvable in its lifetime with its resources. "According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible." https://en.m.wikipedia.org/wiki/StrongARM https://en.m.wikipedia.org/wiki/StrongARM

djbusby 3y ago
Back in the NT4 days, which supported Alpha, my lab had a few of their boxes. Dual 500Mhz (it was ~1998) Huge box with a huge PSU. And we had some cheapo desktop HPs with dual Pentium2(3? (the card edge ones)) at like 450 or 533. Which basically ran circles and sipped power by comparison. Don't remember the exact numbers but only 2 per 15A circuit; with 4 of the x86 per.
akuma73 3y ago
A lot of ex-Alpha engineers went to PA-Semi which Apple then acquired. Those people are responsible for the epic custom Apple ARM CPUs.
- chasil 3y ago
  Like I said, DEC also did StrongARM, which probably gave designers in many areas a new perspective.
- deaddodo 3y ago
  A lot of the Alpha engineers (including Keller) went to AMD and made the Athlon. The Athlon (K7/K8, specifically) was/is considered the spiritual successor to the 21264, by many. But yeah, many ended up looping around to PA Semi (again, including Keller).

pengaru 3y ago

Jim Keller has stated in at least one talk that DEC went bankrupt after Windows NT on Alpha kept crashing because they'd designed the Alpha with weak memory ordering and MS wouldn't implement the necessary memory barriers. Didn't sound like Itanic played a part at all.

p_l 3y ago
Itanic played part after Compaq buyout, where Compaq decided to bank all on Itanium sight unseen of actual usable parts, IIRC. The end result was that they had to restart development of EV7 then restart its production again, because many, many ex-DEC customers didn't want to move to Itanium (customers running Tru64 mostly moved to Linux on amd64 or occasionally to other RISC vendors instead of dealing with HP-UX, whereas OpenVMS customers kept to Alphas which outperformed Itanium usually or moved off the platform completely, with stragglers now moving to amd64)
- javitron 3y ago
  Alpha was on life support by the time Compaq bought DEC. AXP was literally one of the things that basically killed DEC. By the time HP bought Compaq, AXP was on legacy mode. Plus Itanium was as much of an HP architecture as it was intel's, so it made no sense for HP to develop AXP further.

javitron 3y ago

What killed Alpha and high performance MIPS (And eventually SPARC) was simple economics; their design costs grew faster than the revenue they generated. I don't think many of the arm chair CPU experts really understand how expensive it is to design a high performance CPU core.