The Apache #’s pretty much give the game away: An Itanium clocked 50% higher was losing to a 2yo Alpha by about 20% on throughput at peak.
VLIW made sense when Intel wanted to win the FP-heavy workstation market. But while it was in development, integer-heavy web workloads became dominant and that was basically the ballgame.
The world would be much nicer if we still had new Alpha CPUs. It was intended to be a CPU architecture that lasts 25 years and Digital intended the architecture to support a 1000x increase in performance during that time.
Now we have RISC-V reinventing the wheel. Not the worst outcome, but we could have had it so much better...
Not handling unaligned access gracefully is a classic RISC "feature", as part of the general simplification of a processor to its basics. I'm not sure if it's really an Alpha specific thing. Plus they added some instructions to ease the pain in 1996.
The main issue people tend to bring up with Alpha is the very loose memory model, of the "things happen, but different processors may not really agree on the order they happened in" type of thing (plus, isn't it rude to want to know what other cores have in their cache?). Which would be a pain in our modern multicore world.
Of course we don't know how things would've evolved over time, ARM (at least big cores[1]) shifted towards the forgiving model for unaligned access, it's possible over time Alpha would've similarly moved to far more forgiving environment for low level programmers.
[1] On embedded stuff, you're going to the Hardfault handler.
Alpha had a super loosy-goosy memory model because iirc the cache size they wanted couldn’t be built with the performance they needed on the process they had, so they made it from two wholly independent cache banks, both serving the same core through a shared queue.
DEC designed StrongARM pretty much immediately after Alpha shipped because Alpha chips ran hot as frick and DEC engineers didn’t see a path to low-power Alpha.
Itanium was primarily developed by Intel, Itanium 2 primarily by the HP team that also was responsible for the competitive PA-RISC chips. (Or so they say). In any case, Itanium 2 still outperformed much later AMD Opterons and Intel Xeons running at twice the clock in numerical workloads. That’s pretty impressive.
That’s my point: If the demand for high-end compute at the turn of the millennium had looked the same as the demand for high-end compute in 1992, Itanium probably would have conquered the world.
But Tim Berners-Lee had a NeXT and some good ideas…
On a similar note, porting Linux to Itanium — A System Implementor’s Tale [PDF]
https://www.usenix.org/legacy/event/usenix05/tech/general/gr...
and, NonStop on Itanium [PDF]:
https://www.researchgate.net/profile/David_Bernick/publicati...
The Apache #’s pretty much give the game away: An Itanium clocked 50% higher was losing to a 2yo Alpha by about 20% on throughput at peak.
VLIW made sense when Intel wanted to win the FP-heavy workstation market. But while it was in development, integer-heavy web workloads became dominant and that was basically the ballgame.
The world would be much nicer if we still had new Alpha CPUs. It was intended to be a CPU architecture that lasts 25 years and Digital intended the architecture to support a 1000x increase in performance during that time.
Now we have RISC-V reinventing the wheel. Not the worst outcome, but we could have had it so much better...
It couldn't even handle unaligned access in it’s original form. Surely an architecture to last for 25 years.
Not handling unaligned access gracefully is a classic RISC "feature", as part of the general simplification of a processor to its basics. I'm not sure if it's really an Alpha specific thing. Plus they added some instructions to ease the pain in 1996.
The main issue people tend to bring up with Alpha is the very loose memory model, of the "things happen, but different processors may not really agree on the order they happened in" type of thing (plus, isn't it rude to want to know what other cores have in their cache?). Which would be a pain in our modern multicore world.
Of course we don't know how things would've evolved over time, ARM (at least big cores[1]) shifted towards the forgiving model for unaligned access, it's possible over time Alpha would've similarly moved to far more forgiving environment for low level programmers.
[1] On embedded stuff, you're going to the Hardfault handler.
Alpha had a super loosy-goosy memory model because iirc the cache size they wanted couldn’t be built with the performance they needed on the process they had, so they made it from two wholly independent cache banks, both serving the same core through a shared queue.
DEC designed StrongARM pretty much immediately after Alpha shipped because Alpha chips ran hot as frick and DEC engineers didn’t see a path to low-power Alpha.
Itanium was primarily developed by Intel, Itanium 2 primarily by the HP team that also was responsible for the competitive PA-RISC chips. (Or so they say). In any case, Itanium 2 still outperformed much later AMD Opterons and Intel Xeons running at twice the clock in numerical workloads. That’s pretty impressive.
That’s my point: If the demand for high-end compute at the turn of the millennium had looked the same as the demand for high-end compute in 1992, Itanium probably would have conquered the world.
But Tim Berners-Lee had a NeXT and some good ideas…
Amusingly similar to the much more recent slide decks about the x86 port, e.g. https://vmssoftware.com/docs/State_of_Port_20171006.pdf