8 ms·

It's funny thinking back to the hype cycle of Itanium back in the heady days where performance was doubling every year, desktop was king and this was the future

It's funny thinking back to the hype cycle of Itanium back in the heady days where performance was doubling every year, desktop was king and this was the future. Turns out it was more like IBM's MCA / PS2 rather than the future. Compatibility and ubiquity wins. As nearly always.

chx 3y ago
2009 summary https://www.pcmag.com/article2/0,2817,2339629,00.asp https://www.pcmag.com/article2/0,2817,2339629,00.asp > The failure of this chip to do anything more than exist as a niche processor sealed the fate of Intel—and perhaps the entire industry, since from 1997 to 2001 everyone waited for the messiah of chips to take us all to the next level. > It did that all right. It took us to the next level. But we didn't know that the next level was below us, not above. The next level was the basement, in fact. Hopefully Intel won't come up with any more bright ideas like the Itanium. We can't afford to excavate another level down.
- cubefox 3y ago
  This piece sounds like a lot of misrepresentation and exaggeration.
  - chx 3y ago
    Whether the DEC Alpha development stopped because of Merced (as it was called then) or because of the 1997 legal mess https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-dispute/ https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-di... is quite hard to say. The DEC Alpha architecture was planned for 25 years and it certainly was not technical barriers that killed the Alpha 21464.
    - jabl 3y ago
      In the end it was market forces that did it in. Making new chips was (still is!) exponentially more expensive for each generation, and at the same time mass market chips were getting better and better while they could amortize the NRE costs over zillions of chips sold, eating the market from below. And other RISC competitors (and IA-64) were attacking from the sides. DEC just didn't have the customer base or depth of pockets to fund Alpha development. That it was Itanium that ultimately delivered the coup de grace was but the final insult.
      - FullyFunctional 3y ago
        In my limited understanding two factors contributed significantly to Alpha failing. Business-wise, DEC and Ken Olesen were stuck in an old minicomputer mentality and wasn't sufficiently able or willing to "let it loose" and let it take over the market with DEC as the CPU supplier. Technically, Alpha development was taking longer and longer and the schedule slips got worse and worse.
        kstrauser 3y ago
        If the business end had kept the cash rolling in, do you think the technical side could have kept to schedule?
        GrilledChips 3y ago
        It wasn't the technical side that caused the schedule slips. It was constant competition with other aspects of the business, especially the VAX lineup. The VAX 9000 in particular was a $3 billion money pit that didn't make back even 25% of it's development costs and was repeatedly chosen over development of prism and later alpha. Even when it came down to the embarrassingly fast NVAX chip vs the even faster Alhpa, DEC still couldn't get the story straight and lost valuable VAX customers when they could have offered a faster VAX and an upgrade path to Alpha.
        chasil 3y ago
        I worked on a DECStation 5000/240 running Ultrix, in a student job in 1993. DEC should have bought MIPS, and ported VMS to it. Had they made that decision, they might still exist.
        speed_spread 3y ago
        Yeah, DEC needed to scale the Alpha down, even below PCs. A console deal could have given it a few more years and helped with chip economics.
        javitron 3y ago
  - javitron 3y ago
    It is a great representation of the average article written about Itanium. I think the register made most of its revenue from articles about Itanium, where the authors had no clue about what they were talking about. Not defending Itanium. But the average article on computer architecture has been garbage for decades now, it's fascinating.
- vGPU 3y ago
  This reads like it was written by a discount version of chatGPT.
postmodest 3y ago
As someone working in that space at that time, IA64 was still losing to Sparc64 the entire time. We would do big boxes on Solaris and replace older Sun boxes with ia32 Pentium Pros. There wasn't really ever a point at which we thought "hm, RISC isn't working for us, we need VLIW" ...and we were an HP shop!!!
- GrilledChips 3y ago
  Sun was one of the few processor makers who were sceptical and decided to wait and see before cancelling plans for their architecture, and it's nice to hear that worked out for them for a bit before 64-bit x86 ate their lunch. Of course, it's also possible that by that point Sun was already paralysed by infighting between various splinter groups, with no big bad DEC to fight against.
- javitron 3y ago
  The irony being that Itanium is basically a SPARC64 on steroids; both wide, both used huge register windows, and both were in order. the only difference being that Itanium exposed a lot of the superscalar bits to the programmer. I still have no clue why an HP shop would be using Solaris boxes, alas...
brookst 3y ago
I still get confused whether the real name is Itanium or Itanic
- Tsiklon 3y ago
  It’s a beautiful piece of tabloid journalism - jokingly naming Itanium, Itanic after the Titanic.
rasz 3y ago
It was only the future until release date forced it to face the reality. Linus Torvalds in 2003: https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html >Itanium 2 doesn't hold a candle to a P4 on any real-world benchmarks.
- FullyFunctional 3y ago
  Hilariously, it must be read in the context that Linus actually hated the P4 for it's very imbalanced performance.
twoodfin 3y ago
Compatibility and ubiquity wins. As nearly always. I’m not particularly confused about Intel’s perspective on compatibility: Even at the time, there were several examples of successful platform CPU transitions across architectural “full breaks”. Apple going from 68k to PowerPC is the closest analogy for Intel, and if the Itanium performance and software (compiler) story had played out as Intel envisioned they likely would have been fine. But as for ubiquity, I’m befuddled. As far as I’ve been able to determine—having lived through it and followed many retrospective threads like this looking for new evidence—Intel had no plans on any useful timeline to turn Itanium into a (non-workstation) desktop or laptop chip. Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
- flashback2199 3y ago
  > Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that. Oh but they did :)
- bombcar 3y ago
  I think it's the case that they wanted to believe that, because the other story, that all the major "big iron" companies would be absolutely and totally forever wrecked by stupid free Linux running on stupid cheap whiteboxes was simply too horrible to envision.
  - twoodfin 3y ago
    Data center computing being dominated by commodity Linux running on commodity x86 PC architecture—for which the best CPUs were not commodities, but rather made exclusively by Intel—was likely the best of all possible worlds for them! Going back to at least the i432, Intel seems to have had a deep vein of “mainframe envy” in their culture and strategic thinking. It seems that somehow the market (and a bit of trailblazing into x86-64 by AMD) saved them from themselves.
    - 3y ago
bitwize 3y ago
Itanic was hype from the word go. Intel tried and failed twice to make "VLIW CPUs that rely on 'sufficiently smart' HLL compilers doing the right instruction packings" a thing before Itanium came along (iAPX 432 and i860). I think someone very high up at Intel was in love with the idea despite its repeated failures. Alpha was clearly the future -- and Itanic ruined Alpha. We didn't even get to see it live on inside some other corporate sarlacc.
- BirAdam 3y ago
  Well, zero speculation would have saved from all of the exploits over the years… so there’s that.
- fulafel 3y ago
  I hadn't heard about compiler vs 432 before, any links?
  - p_l 3y ago
    I do recall some discussion about combination of really bad code generation combined with some ridiculously bad design decisions (I think it might have been total lack of cache?)
  - tjalfi 3y ago
    The blog entry Revisiting the Intel 432[0] and the cited paper Performance Effects of Architectural Complexity in the Intel 432[1] discuss the compiler issues. [0] https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel-432/ https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel... [1] https://dl.acm.org/doi/pdf/10.1145/45059.214411 https://dl.acm.org/doi/pdf/10.1145/45059.214411
  - bitwize 3y ago
    All I know is the Wikipedia article references a crappy Ada compiler whose lack of optimization made it run slower than a 286: https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432
kstrauser 3y ago
> Compatibility and ubiquity wins. As nearly always. In this case, that means AMD showing up with the first x86-compatible 64-bit CPUs killed Itanium dead. For big software projects already running on x86, there were 2 options: - Port everything to a new architecture that only looked good in specific benchmarks, cross your fingers, and hope for the best. - Keep running your code on new 64-bit CPUs that were backward compatible with your existing code, then recompile for 64-bit as you got around to it. As a bonus, amd64/x86-64 CPUs were faster than the P4 chips that practically needed 3 phase power to boot up. It was kind of a no brainer.
justin66 3y ago
> Turns out it was more like IBM's MCA / PS2 rather than the future. It was quite a bit worse than that. If you ignore the horror of IBM vendor lock-in, which in retrospect made the whole thing untenable, and the overpriced nature of the systems, MCA was a fine thing for its time. The PS/2s had some nice features. They were compatible with everyone's DOS and Windows stuff, even if IBM would have preferred you use OS/2, and so on. Itanium was a piece of crap, even if you could somehow ignore the cost and lock-in.
fulafel 3y ago
> Compatibility and ubiquity wins. As nearly always. Counterexample: GPU compute.
spamizbad 3y ago
> Compatibility and ubiquity wins. As nearly always. I'm not sure that was Itanium's only problem. Intel's Itanium launch focused on a market that was not captured by the so-called "Wintel" monopoly: high performance servers. The software support needed in this market was relatively narrow. Nevertheless, it failed there too. The biggest issue with Itanium is that the juice was never worth the squeeze. It was expensive. The cost to migrate your existing 64bit systems never made sense. So, you might ask, what about 32-bit shops that needed to make the leap to 64 bits? Well, by the time intel and its vendors started getting costs under control, the AMD Opteron hit the scene with commodity 64bit hardware that had the added benefit of full backwards compatibility. And that pretty much killed it.

chx 3y ago

2009 summary https://www.pcmag.com/article2/0,2817,2339629,00.asp https://www.pcmag.com/article2/0,2817,2339629,00.asp > The failure of this chip to do anything more than exist as a niche processor sealed the fate of Intel—and perhaps the entire industry, since from 1997 to 2001 everyone waited for the messiah of chips to take us all to the next level. > It did that all right. It took us to the next level. But we didn't know that the next level was below us, not above. The next level was the basement, in fact. Hopefully Intel won't come up with any more bright ideas like the Itanium. We can't afford to excavate another level down.

cubefox 3y ago
This piece sounds like a lot of misrepresentation and exaggeration.
- chx 3y ago
  Whether the DEC Alpha development stopped because of Merced (as it was called then) or because of the 1997 legal mess https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-dispute/ https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-di... is quite hard to say. The DEC Alpha architecture was planned for 25 years and it certainly was not technical barriers that killed the Alpha 21464.
  - jabl 3y ago
    In the end it was market forces that did it in. Making new chips was (still is!) exponentially more expensive for each generation, and at the same time mass market chips were getting better and better while they could amortize the NRE costs over zillions of chips sold, eating the market from below. And other RISC competitors (and IA-64) were attacking from the sides. DEC just didn't have the customer base or depth of pockets to fund Alpha development. That it was Itanium that ultimately delivered the coup de grace was but the final insult.
    - FullyFunctional 3y ago
      In my limited understanding two factors contributed significantly to Alpha failing. Business-wise, DEC and Ken Olesen were stuck in an old minicomputer mentality and wasn't sufficiently able or willing to "let it loose" and let it take over the market with DEC as the CPU supplier. Technically, Alpha development was taking longer and longer and the schedule slips got worse and worse.
      - kstrauser 3y ago
        If the business end had kept the cash rolling in, do you think the technical side could have kept to schedule?
      - GrilledChips 3y ago
        It wasn't the technical side that caused the schedule slips. It was constant competition with other aspects of the business, especially the VAX lineup. The VAX 9000 in particular was a $3 billion money pit that didn't make back even 25% of it's development costs and was repeatedly chosen over development of prism and later alpha. Even when it came down to the embarrassingly fast NVAX chip vs the even faster Alhpa, DEC still couldn't get the story straight and lost valuable VAX customers when they could have offered a faster VAX and an upgrade path to Alpha.
        chasil 3y ago
        I worked on a DECStation 5000/240 running Ultrix, in a student job in 1993. DEC should have bought MIPS, and ported VMS to it. Had they made that decision, they might still exist.
      - speed_spread 3y ago
        Yeah, DEC needed to scale the Alpha down, even below PCs. A console deal could have given it a few more years and helped with chip economics.
        javitron 3y ago
- javitron 3y ago
  It is a great representation of the average article written about Itanium. I think the register made most of its revenue from articles about Itanium, where the authors had no clue about what they were talking about. Not defending Itanium. But the average article on computer architecture has been garbage for decades now, it's fascinating.
vGPU 3y ago
This reads like it was written by a discount version of chatGPT.

postmodest 3y ago

As someone working in that space at that time, IA64 was still losing to Sparc64 the entire time. We would do big boxes on Solaris and replace older Sun boxes with ia32 Pentium Pros. There wasn't really ever a point at which we thought "hm, RISC isn't working for us, we need VLIW" ...and we were an HP shop!!!

GrilledChips 3y ago
Sun was one of the few processor makers who were sceptical and decided to wait and see before cancelling plans for their architecture, and it's nice to hear that worked out for them for a bit before 64-bit x86 ate their lunch. Of course, it's also possible that by that point Sun was already paralysed by infighting between various splinter groups, with no big bad DEC to fight against.
javitron 3y ago
The irony being that Itanium is basically a SPARC64 on steroids; both wide, both used huge register windows, and both were in order. the only difference being that Itanium exposed a lot of the superscalar bits to the programmer. I still have no clue why an HP shop would be using Solaris boxes, alas...

brookst 3y ago

I still get confused whether the real name is Itanium or Itanic

Tsiklon 3y ago
It’s a beautiful piece of tabloid journalism - jokingly naming Itanium, Itanic after the Titanic.

rasz 3y ago

It was only the future until release date forced it to face the reality. Linus Torvalds in 2003: https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html >Itanium 2 doesn't hold a candle to a P4 on any real-world benchmarks.

FullyFunctional 3y ago
Hilariously, it must be read in the context that Linus actually hated the P4 for it's very imbalanced performance.

twoodfin 3y ago

Compatibility and ubiquity wins. As nearly always. I’m not particularly confused about Intel’s perspective on compatibility: Even at the time, there were several examples of successful platform CPU transitions across architectural “full breaks”. Apple going from 68k to PowerPC is the closest analogy for Intel, and if the Itanium performance and software (compiler) story had played out as Intel envisioned they likely would have been fine. But as for ubiquity, I’m befuddled. As far as I’ve been able to determine—having lived through it and followed many retrospective threads like this looking for new evidence—Intel had no plans on any useful timeline to turn Itanium into a (non-workstation) desktop or laptop chip. Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.

flashback2199 3y ago
> Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that. Oh but they did :)
bombcar 3y ago
I think it's the case that they wanted to believe that, because the other story, that all the major "big iron" companies would be absolutely and totally forever wrecked by stupid free Linux running on stupid cheap whiteboxes was simply too horrible to envision.
- twoodfin 3y ago
  Data center computing being dominated by commodity Linux running on commodity x86 PC architecture—for which the best CPUs were not commodities, but rather made exclusively by Intel—was likely the best of all possible worlds for them! Going back to at least the i432, Intel seems to have had a deep vein of “mainframe envy” in their culture and strategic thinking. It seems that somehow the market (and a bit of trailblazing into x86-64 by AMD) saved them from themselves.
  - 3y ago

bitwize 3y ago

Itanic was hype from the word go. Intel tried and failed twice to make "VLIW CPUs that rely on 'sufficiently smart' HLL compilers doing the right instruction packings" a thing before Itanium came along (iAPX 432 and i860). I think someone very high up at Intel was in love with the idea despite its repeated failures. Alpha was clearly the future -- and Itanic ruined Alpha. We didn't even get to see it live on inside some other corporate sarlacc.

BirAdam 3y ago
Well, zero speculation would have saved from all of the exploits over the years… so there’s that.
fulafel 3y ago
I hadn't heard about compiler vs 432 before, any links?
- p_l 3y ago
  I do recall some discussion about combination of really bad code generation combined with some ridiculously bad design decisions (I think it might have been total lack of cache?)
- tjalfi 3y ago
  The blog entry Revisiting the Intel 432[0] and the cited paper Performance Effects of Architectural Complexity in the Intel 432[1] discuss the compiler issues. [0] https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel-432/ https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel... [1] https://dl.acm.org/doi/pdf/10.1145/45059.214411 https://dl.acm.org/doi/pdf/10.1145/45059.214411
- bitwize 3y ago
  All I know is the Wikipedia article references a crappy Ada compiler whose lack of optimization made it run slower than a 286: https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432

kstrauser 3y ago

> Compatibility and ubiquity wins. As nearly always. In this case, that means AMD showing up with the first x86-compatible 64-bit CPUs killed Itanium dead. For big software projects already running on x86, there were 2 options: - Port everything to a new architecture that only looked good in specific benchmarks, cross your fingers, and hope for the best. - Keep running your code on new 64-bit CPUs that were backward compatible with your existing code, then recompile for 64-bit as you got around to it. As a bonus, amd64/x86-64 CPUs were faster than the P4 chips that practically needed 3 phase power to boot up. It was kind of a no brainer.

justin66 3y ago

> Turns out it was more like IBM's MCA / PS2 rather than the future. It was quite a bit worse than that. If you ignore the horror of IBM vendor lock-in, which in retrospect made the whole thing untenable, and the overpriced nature of the systems, MCA was a fine thing for its time. The PS/2s had some nice features. They were compatible with everyone's DOS and Windows stuff, even if IBM would have preferred you use OS/2, and so on. Itanium was a piece of crap, even if you could somehow ignore the cost and lock-in.

fulafel 3y ago

> Compatibility and ubiquity wins. As nearly always. Counterexample: GPU compute.

spamizbad 3y ago

> Compatibility and ubiquity wins. As nearly always. I'm not sure that was Itanium's only problem. Intel's Itanium launch focused on a market that was not captured by the so-called "Wintel" monopoly: high performance servers. The software support needed in this market was relatively narrow. Nevertheless, it failed there too. The biggest issue with Itanium is that the juice was never worth the squeeze. It was expensive. The cost to migrate your existing 64bit systems never made sense. So, you might ask, what about 32-bit shops that needed to make the leap to 64 bits? Well, by the time intel and its vendors started getting costs under control, the AMD Opteron hit the scene with commodity 64bit hardware that had the added benefit of full backwards compatibility. And that pretty much killed it.