Hacker News Reader

Comment by failuser | Hacker News Reader

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

View on HN

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.

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).

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.

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.

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

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.

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

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.

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.

Like I said, DEC also did StrongARM, which probably gave designers in many areas a new perspective.

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).

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.

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.

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)

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.

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.

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

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.

Reply on news.ycombinator.com