4 ms·

Itanium wasn’t a turd. It was just not compatible with x86. And that was enough to sink it.

bombcar 1y ago
IIRC it didn't even do great against POWER and other bespoke OS/Chip combos, though it did way better there than generic x86.
- p_l 1y ago
  With ex-Digital customers running OpenVMS, they held onto last-generation Alpha machines because they were substantially faster than the new Itanium ones in all practical uses. This is also why HP was finally forced to resurrect the nearly-complete EV7 chips
philipkglass 1y ago
I used it for numerical simulations and it was very fast there. But on my workstation many common programs like "grep" were slower than on my cheap Athlon machine. (Both were running Red Hat Linux at the time.) I don't know how much of that was a compiler problem and how much was an architecture problem; the Itanium numerical simulation code was built with Intel's own compiler but all the system utilities were built with GNU compilers.
fooker 1y ago
>Itanium wasn’t a turd It required immense multi-year efforts from compiler teams to get passable performance with Itanium. And passable wasn't good enough.
- bombcar 1y ago
  Wasn't the only compiler that produced code worth anything for Itanium the paid one from Intel? I seem to recall complaining about it on the GCC lists.
  - hawflakes 1y ago
    I lost track of it but HP, as co-architects, had its own compiler team working on it. I think SGI also had efforts to target ia64 as well. But the EPIC (Explicitly Parallel Instruction Computing) didn't really catch on. VLIW would need recompilation on each new chip but EPIC promised it would still run. https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
    - fooker 1y ago
      In the compiler world, these HP compiler folks are leading compiler teams/orgs at ~all the tech companies now, while almost none of the Intel compiler people seem to be around.
      - jabl 1y ago
        Are you sure about that? If my memory serves, a lot of the Intel compiler people were transferred from HP? At least in the Fortran world, the Fortran frontend for the Intel compiler traces it's lineage back to DEC Fortran (for VAX and later Alpha) -> Compaq Visual Fortran (for Windows) -> Intel Fortran.
    - nextos 1y ago
      Yes, SGI sold quite a lot of high-end IA-64 machines for HPCs, e.g. https://en.wikipedia.org/wiki/SGI_Altix https://en.wikipedia.org/wiki/SGI_Altix
  - hajile 1y ago
    NOTHING produced good code for the original Itanium which is why they switched gears REALLY early on. Intel first publicly mentioned Poulson all the way back in 2005 just FOUR years after the original chip was launched. Poulson was basically a traditional out-of-order CPU core that even had hyperthreading[0]. They knew really early on that the designs just weren't that good. This shouldn't have been a surprise to Intel as they'd already made a VLIW CPU in the 90s (i860) that failed spectacularly. [0]https://www.realworldtech.com/poulson/ https://www.realworldtech.com/poulson/
- Joel_Mckay 1y ago
  The IA-64 architecture had too much granularity of control dropped into software. Thus, reliable compiler designs were much more difficult to build. It wasn't a bad chip, but like Cell or modern Dojo tiles most people couldn't run it without understanding parallelism and core metastability. amd64 wasn't initially perfect either, but was accessible for mere mortals. =3
eej71 1y ago
Itanium was mostly a turd because it pushed so many optimization issues onto the compiler.
- CoastalCoder 1y ago
  IIRC, wasn't part of the issue that compile-time instruction scheduling was a poor match with speculative execution and/or hardware-based branch prediction? I.e., the compiler had no access to information that's only revealed at runtime?
  - duskwuff 1y ago
    Yes, absolutely. Itanium was designed with the expectation that memory speed/latency would keep pace with CPUs - it didn't.
- _flux 1y ago
  Could it have been a good target for e.g. Java JIT? It would be able to instrument the code at times, and then generate more optimal code for it?
  - philipkglass 1y ago
    I think you may be right. It's hard for me to find then-contemporary benchmarks from 20 years ago, but this snarky Register article mentions it indirectly: https://www.theregister.com/2004/01/27/have_a_reality_check_you/ https://www.theregister.com/2004/01/27/have_a_reality_check_... SPECjbb2000 (an important enterprise server benchmark): Itanic holds a slim (under 3%) lead over AMD64 at the 4-processor node size and another slim (under 4%) lead over POWER4+ at the 32-processor node size - hardly 'destroying' the competition, once again. It was slightly faster than contemporary high-performance processors on Java. It was also really good at floating point performance. It was also significantly more expensive than AMD64 for server applications if you could scale your servers horizontally instead of vertically.
textlapse 1y ago
I have worked next to an Itanium machine. It sounds like a helicopter - barely able to meet the performance requirements. We have come a long way from that to arm64 and amd64 as the default.
- Joel_Mckay 1y ago
  The stripped down ARM 8/9 for AArch64 is good for a lot of use-cases, but most of the vendor specific ASIC advanced features were never enabled for reliability reasons. ARM is certainly better than before, but could have been much better. =3
cmrdporcupine 1y ago
Itanium was pointless when Alpha existed already and was already getting market penetration in the high end market. Intel played disgusting corporate politics to kill it and then push the ugly failed Itanium to market, only to have to panic back to x86_64 later. I have no idea how/why Intel got a second life after that, but they did. Which is a shame. A sane market would have punished them and we all would have moved on.
- dessimus 1y ago
  > I have no idea how/why Intel got a second life after that, but they did. For the same reason the line "No one ever got fired for buying IBM." exists. Buying AMD at large companies was seen as a gamble that deciders weren't will to make. Even now, if you just call up your account managers at Dell, HP, or Lenovo asking for servers or PCs, they are going to quote you Intel builds unless you specifically ask. I don't think I've ever been asked by my sales reps if I wanted an Intel or AMD CPU. Just how many slots/cores, etc.
  - bombcar 1y ago
    The Intel chipsets were phenomenally stable; the AMD ones were always plagued by weird issues.
- loloquwowndueo 1y ago
  “Sane market” sounds like an oxymoron, technology markets have multiple failed attempts at doing the sane thing.
- toast0 1y ago
  Historically, when Intel is on their game, they have great products, and better than most support for OEMs and integrators. They're also very effective at marketting and arm twisting. The arm twisting gets them through rough times like itanium and pentium4 + rambus, etc. I still think they can recover from the 10nm fab problems, even though they're taking their sweet time.
- panick21_ 1y ago
  Gordon Moore tried to link up with Intel when he was at DEC. Alpha would have become Intels 64 bit architecture. This of course didn't happen and Intel instead linked up with DEC biggest competitor HP, and adopted their, much, much worse VLIW architecture. Imagine a future where Intel and Apple both adopt DEC and Alpha instead of Intel HP and Apple IBM.
hawflakes 1y ago
Itanium was compatible with x86. In fact, it booted into x86 mode. Merced, the first implementation had a part of the chip called the IVE, Intel Value Engine, that implemented x86 very slowly. You would boot in x86 mode and run some code to switch to ia64 mode. HP saw the end of the road for their solo efforts on PA-RISC and Intel eyed the higher end market against SPARC, MIPS, POWER, and Alpha (hehe. all those caps) so they banded together to tackle the higher end. But as AMD proved, you could win by scaling up instead of dropping an all-new architecture. * worked at HP during the HP-Intel Highly Confidential project.
kstrauser 1y ago
It absolutely was. It was possible, hypothetically, to write a chunk of code that ran very fast. There were any number of very small bits of high-profile code which did this. However, it was impossible to make general-purpose, not-manually-tuned code run fast on it. Itanium placed demands on compiler technology that simple didn't exist, and probably still don't. Basically, you could write some tuned assembly that would run fast on one specific Itanium CPU release by optimizing for its exact number of execution units, etc. It was not possible to run `./configure && make && make install` for anything not designed with that level of care and end up with a binary that didn't run like frozen molasses. I had to manage one of these pigs in a build farm. On paper, it should've been one of the more powerful servers we owned. In practice, the Athlon servers were several times faster at any general purpose workloads.
jcranmer 1y ago
I acquired a copy of the Itanium manuals, and in flicking through it, you can barely get through a page before going "you did WHAT?" over some feature.
- tptacek 1y ago
  Example example example example must see examples!
  - jcranmer 1y ago
    Some of the examples: * Itanium has register windows. * Itanium has register rotations, so that you can modulo-schedule a loop. * Itanium has so many registers that a context switch is going to involve spilling several KB of memory. * The main registers have "Not-a-Thing" values to be able to handle things like speculative loads that would have trapped. Handling this for register spills (or context switches!) appears to be "fun." * It's a bi-endian architecture. * The way you pack instructions in the EPIC encoding is... fun. * The rules of how you can execute instructions mean that you kind of have branch delay slots, but not really. * There are four floating-point environments because why not. * Also, Itanium is predicated. * The hints, oh god the hints. It feels like every time someone came up with an idea for a hint that might be useful to the processor, it was thrown in there. How is a compiler supposed to be able to generate all of these hints? * It's an architecture that's complicated enough that you need to handwrite assembly to get good performance, but the assembly has enough arcane rules that handwriting assembly is unnecessarily difficult.
    - tptacek 1y ago
      I am not disappointed. Having-but-not-really-having delay slots is my favorite thing here. Thank you, by the way!
    - lambda_foo 1y ago
      The fact that Itanium had register windows was such a strange choice. I thought they had been shown to not be worthwhile like branch delay slots in MIPS. Basically hangovers from the early constraints of hardware implementations.
Findecanor 1y ago
The Itanium had some interesting ideas executed poorly. It was a bloated design by committee. It should have been iterated on a bit before it was released to the world, but Intel was stressed by there being several 64-bit RISC-processors on the market already.

IIRC it didn't even do great against POWER and other bespoke OS/Chip combos, though it did way better there than generic x86.

p_l 1y ago
With ex-Digital customers running OpenVMS, they held onto last-generation Alpha machines because they were substantially faster than the new Itanium ones in all practical uses. This is also why HP was finally forced to resurrect the nearly-complete EV7 chips

philipkglass 1y ago

I used it for numerical simulations and it was very fast there. But on my workstation many common programs like "grep" were slower than on my cheap Athlon machine. (Both were running Red Hat Linux at the time.) I don't know how much of that was a compiler problem and how much was an architecture problem; the Itanium numerical simulation code was built with Intel's own compiler but all the system utilities were built with GNU compilers.

fooker 1y ago

>Itanium wasn’t a turd It required immense multi-year efforts from compiler teams to get passable performance with Itanium. And passable wasn't good enough.

bombcar 1y ago
Wasn't the only compiler that produced code worth anything for Itanium the paid one from Intel? I seem to recall complaining about it on the GCC lists.
- hawflakes 1y ago
  I lost track of it but HP, as co-architects, had its own compiler team working on it. I think SGI also had efforts to target ia64 as well. But the EPIC (Explicitly Parallel Instruction Computing) didn't really catch on. VLIW would need recompilation on each new chip but EPIC promised it would still run. https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
  - fooker 1y ago
    In the compiler world, these HP compiler folks are leading compiler teams/orgs at ~all the tech companies now, while almost none of the Intel compiler people seem to be around.
    - jabl 1y ago
      Are you sure about that? If my memory serves, a lot of the Intel compiler people were transferred from HP? At least in the Fortran world, the Fortran frontend for the Intel compiler traces it's lineage back to DEC Fortran (for VAX and later Alpha) -> Compaq Visual Fortran (for Windows) -> Intel Fortran.
  - nextos 1y ago
    Yes, SGI sold quite a lot of high-end IA-64 machines for HPCs, e.g. https://en.wikipedia.org/wiki/SGI_Altix https://en.wikipedia.org/wiki/SGI_Altix
- hajile 1y ago
  NOTHING produced good code for the original Itanium which is why they switched gears REALLY early on. Intel first publicly mentioned Poulson all the way back in 2005 just FOUR years after the original chip was launched. Poulson was basically a traditional out-of-order CPU core that even had hyperthreading[0]. They knew really early on that the designs just weren't that good. This shouldn't have been a surprise to Intel as they'd already made a VLIW CPU in the 90s (i860) that failed spectacularly. [0]https://www.realworldtech.com/poulson/ https://www.realworldtech.com/poulson/
Joel_Mckay 1y ago
The IA-64 architecture had too much granularity of control dropped into software. Thus, reliable compiler designs were much more difficult to build. It wasn't a bad chip, but like Cell or modern Dojo tiles most people couldn't run it without understanding parallelism and core metastability. amd64 wasn't initially perfect either, but was accessible for mere mortals. =3

eej71 1y ago

Itanium was mostly a turd because it pushed so many optimization issues onto the compiler.

CoastalCoder 1y ago
IIRC, wasn't part of the issue that compile-time instruction scheduling was a poor match with speculative execution and/or hardware-based branch prediction? I.e., the compiler had no access to information that's only revealed at runtime?
- duskwuff 1y ago
  Yes, absolutely. Itanium was designed with the expectation that memory speed/latency would keep pace with CPUs - it didn't.
_flux 1y ago
Could it have been a good target for e.g. Java JIT? It would be able to instrument the code at times, and then generate more optimal code for it?
- philipkglass 1y ago
  I think you may be right. It's hard for me to find then-contemporary benchmarks from 20 years ago, but this snarky Register article mentions it indirectly: https://www.theregister.com/2004/01/27/have_a_reality_check_you/ https://www.theregister.com/2004/01/27/have_a_reality_check_... SPECjbb2000 (an important enterprise server benchmark): Itanic holds a slim (under 3%) lead over AMD64 at the 4-processor node size and another slim (under 4%) lead over POWER4+ at the 32-processor node size - hardly 'destroying' the competition, once again. It was slightly faster than contemporary high-performance processors on Java. It was also really good at floating point performance. It was also significantly more expensive than AMD64 for server applications if you could scale your servers horizontally instead of vertically.

textlapse 1y ago

I have worked next to an Itanium machine. It sounds like a helicopter - barely able to meet the performance requirements. We have come a long way from that to arm64 and amd64 as the default.

Joel_Mckay 1y ago
The stripped down ARM 8/9 for AArch64 is good for a lot of use-cases, but most of the vendor specific ASIC advanced features were never enabled for reliability reasons. ARM is certainly better than before, but could have been much better. =3

cmrdporcupine 1y ago

Itanium was pointless when Alpha existed already and was already getting market penetration in the high end market. Intel played disgusting corporate politics to kill it and then push the ugly failed Itanium to market, only to have to panic back to x86_64 later. I have no idea how/why Intel got a second life after that, but they did. Which is a shame. A sane market would have punished them and we all would have moved on.

dessimus 1y ago
> I have no idea how/why Intel got a second life after that, but they did. For the same reason the line "No one ever got fired for buying IBM." exists. Buying AMD at large companies was seen as a gamble that deciders weren't will to make. Even now, if you just call up your account managers at Dell, HP, or Lenovo asking for servers or PCs, they are going to quote you Intel builds unless you specifically ask. I don't think I've ever been asked by my sales reps if I wanted an Intel or AMD CPU. Just how many slots/cores, etc.
- bombcar 1y ago
  The Intel chipsets were phenomenally stable; the AMD ones were always plagued by weird issues.
loloquwowndueo 1y ago
“Sane market” sounds like an oxymoron, technology markets have multiple failed attempts at doing the sane thing.
toast0 1y ago
Historically, when Intel is on their game, they have great products, and better than most support for OEMs and integrators. They're also very effective at marketting and arm twisting. The arm twisting gets them through rough times like itanium and pentium4 + rambus, etc. I still think they can recover from the 10nm fab problems, even though they're taking their sweet time.
panick21_ 1y ago
Gordon Moore tried to link up with Intel when he was at DEC. Alpha would have become Intels 64 bit architecture. This of course didn't happen and Intel instead linked up with DEC biggest competitor HP, and adopted their, much, much worse VLIW architecture. Imagine a future where Intel and Apple both adopt DEC and Alpha instead of Intel HP and Apple IBM.

hawflakes 1y ago

Itanium was compatible with x86. In fact, it booted into x86 mode. Merced, the first implementation had a part of the chip called the IVE, Intel Value Engine, that implemented x86 very slowly. You would boot in x86 mode and run some code to switch to ia64 mode. HP saw the end of the road for their solo efforts on PA-RISC and Intel eyed the higher end market against SPARC, MIPS, POWER, and Alpha (hehe. all those caps) so they banded together to tackle the higher end. But as AMD proved, you could win by scaling up instead of dropping an all-new architecture. * worked at HP during the HP-Intel Highly Confidential project.

kstrauser 1y ago

It absolutely was. It was possible, hypothetically, to write a chunk of code that ran very fast. There were any number of very small bits of high-profile code which did this. However, it was impossible to make general-purpose, not-manually-tuned code run fast on it. Itanium placed demands on compiler technology that simple didn't exist, and probably still don't. Basically, you could write some tuned assembly that would run fast on one specific Itanium CPU release by optimizing for its exact number of execution units, etc. It was not possible to run `./configure && make && make install` for anything not designed with that level of care and end up with a binary that didn't run like frozen molasses. I had to manage one of these pigs in a build farm. On paper, it should've been one of the more powerful servers we owned. In practice, the Athlon servers were several times faster at any general purpose workloads.

jcranmer 1y ago

I acquired a copy of the Itanium manuals, and in flicking through it, you can barely get through a page before going "you did WHAT?" over some feature.

tptacek 1y ago
Example example example example must see examples!
- jcranmer 1y ago
  Some of the examples: * Itanium has register windows. * Itanium has register rotations, so that you can modulo-schedule a loop. * Itanium has so many registers that a context switch is going to involve spilling several KB of memory. * The main registers have "Not-a-Thing" values to be able to handle things like speculative loads that would have trapped. Handling this for register spills (or context switches!) appears to be "fun." * It's a bi-endian architecture. * The way you pack instructions in the EPIC encoding is... fun. * The rules of how you can execute instructions mean that you kind of have branch delay slots, but not really. * There are four floating-point environments because why not. * Also, Itanium is predicated. * The hints, oh god the hints. It feels like every time someone came up with an idea for a hint that might be useful to the processor, it was thrown in there. How is a compiler supposed to be able to generate all of these hints? * It's an architecture that's complicated enough that you need to handwrite assembly to get good performance, but the assembly has enough arcane rules that handwriting assembly is unnecessarily difficult.
  - tptacek 1y ago
    I am not disappointed. Having-but-not-really-having delay slots is my favorite thing here. Thank you, by the way!
  - lambda_foo 1y ago
    The fact that Itanium had register windows was such a strange choice. I thought they had been shown to not be worthwhile like branch delay slots in MIPS. Basically hangovers from the early constraints of hardware implementations.

Findecanor 1y ago

The Itanium had some interesting ideas executed poorly. It was a bloated design by committee. It should have been iterated on a bit before it was released to the world, but Intel was stressed by there being several 64-bit RISC-processors on the market already.