6 ms·

432 was a pretty interesting flop, but surely the ia64 has to rank up there. it would be interesting to try to chart some of the features that show up in vario

432 was a pretty interesting flop, but surely the ia64 has to rank up there. it would be interesting to try to chart some of the features that show up in various chips. for instance, 64k segments in both 432 and 286+, or VLIW in 860 and ia64.

ghaff 4y ago
One difference is that, according to the article, Intel actually learned quite a bit technically from the 432 even though it was a commercial flop. It's hard to see much of a silver lining in IA64/Itanium for either Intel or HP--or, indeed, for all the other companies that wasted resources on Itanium if only because they felt they had to cover their bases.
- l1k 4y ago
  A lot of RISC CPU arches which were popular in the 1990's declined because their promulgators stopped investments and bet on switching to IA64 instead. Around the year 2000, VLIW was seen as the future and all the CISC and RISC architectures were considered obsolete. That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium.
  - ghaff 4y ago
    It's more complicated than that. Sun didn't slow down on UltraSPARC or make an Itanium side bet. IBM did (and continues to) place their big hardware bet on Power--Itanium was mostly a cover your bases thing. I don't know what HP would have done--presumably either gone their own way with VLIW or kept PA-RISC going. Pretty much all the other RISC/Unix players had to go to a standard processor; some were already on x86. Intel mostly recovered from Itanium specifically but it didn't do them any favors.
    - panick21_ 4y ago
      Sun didn't slow down on UltraSPARC but they were just not very good at designing processors.
    - sliken 4y ago
      Actually, they did. Intel promised aggressive delivery schedule, performance ramp, and performance. The industry took it hook, line, and sinker. While AMD decided not to limit 64 bit to the high end and brought out x86-64. Sun did a port IA64 port of solaris, which is definitely an itanium side bet. HP was involved in the IA64 effort and definitely was planning on the replacement of pa-risc from day 1.
      - davidgay 4y ago
        > HP was involved in the IA64 effort and definitely was planning on the replacement of pa-risc from day 1. As my memory remembers and https://en.wikipedia.org/wiki/Itanium https://en.wikipedia.org/wiki/Itanium agrees, Itanium originated at HP. So yes, a replacement for pa-risc from day 1, but even more so...
        rodgerd 4y ago
        Another way to look at the Itanic is that HP somehow conned Intel into betting the farm on building HP-PA3 for HP. Which is pretty impressive.
  - Dalewyn 4y ago
    >That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium. In that sense, Itanium was a resounding success for Intel (and AMD).
    - panick21_ 4y ago
      Itanium was a success right until they actually made a chip. What they should have done is hype Itanium and then they day it came out they should have said yeah this was a joke, what we did is buy Alpha from Compaq and its literally just Alpha with x86 comparability mode. Then they would have dominated.
  - foobiekr 4y ago
    This isn't really true. IBM/Motorola need to own the failure of POWER and PowerPC and MIPS straight up died on the performance side. Sun continued with Ultrasparc. It wasn't that IA64 killed them, it's that they were getting shaky and IA64 appealed _because_ of that. Plus the lack of a 64bit x86.
    - panick21_ 4y ago
      Its simply economics Intel had the volume. Sun and SGI simply didn't have the economics to invest the same amount, and they were also not chip company, the both didn't invest enough in chip design or invested it wrongly. Sun spend an unbelievable amount of money on dumb ass processor projects. Towards the end of the 90s all of them realized their business model would not do well against Intel, so pretty much all of them were looking for an exit and IA64 hype basically killed most of them. Sun stuck it out with Sparc with mixed results. IBM POWER continues but in a thin slice of the market. Ironically there was a section of Digital and Intel who thought that Alpha should be the bases of 64 bit x86. That would have made Intel pretty dominate. Alpha (maybe a TSO version) with 32 bit x86 comparability mode.
      - PAPPPmAc 4y ago
        Look closely at AMD designs (and staff) of the very late 90s and early 2000s and/or all modern x86 parts and see that ...more or less, that's what happened, just not with an Alpha mode. Dirk Meyer (Co-Architect of the DEC Alpha 21064 and 21264) lead the K7 (Athlon) project, and they run on a licensed EV6 bus borrowed from the Alpha. Jim Keller (Co-Architect of the DEC Alpha 21164 21264) lead the K8 (first gen x86-64) project, and there are a number of design decisions in the K8 evocative of the later Alpha designs. The vast majority of x86 parts since the (NexGen Nx686 which became) AMD K6 and Pentium Pro (P6) have been internal RISC-ish cores with decoders that ingest x86 instructions and chunk them up to be scheduled on an internal RISC architecture. It has turned out to sort of be a better-than-both-worlds thing almost by accident. A major part of what did in the VLIW-ish designs was that "You can't statically schedule dynamic behavior" and a major problem for the RISC designs was that exposing architectural innovations on a RISC requires you change the ISA and/or memory behavior in visible ways from generation to generation, interfering with compatability so... the RISC-behind-x86-decoder designs get to follow the state of the art changing whatever they need to behind the decoder without breaking compatibility AND get to have the decoder do the micro-scheduling dynamically.
- _0w8t 4y ago
  Itanic was a flop due to AMD releasing 64bit CPU. And I still think Intel learned a lot from its failure if not from the technology but business-wise. Just stick to improving the existing architecture while keeping backward-compatibility.
  - markhahn 4y ago
    VLIW was really marooned in time: driven by overconfidence in the compiler (which had shown that you could actually expose pipeline hazards), and underestimates of the coming abundance of transistors (which make superscalar OoO really take off, along with giant onchip caches). well, and multicore to sop up even more available transistors.
    - panick21_ 4y ago
      The problem is that VLIW has already proven not to work in the 90s with lots of companies investing money in it but not making it a product. EPIC was basically VLIW++ with lots of added stuff that should overcome the issues with it, but not doing that successfully. I don't think they underestimated the amount of transistors, they just thought that EPIC would be a better way to use them. OoO had already proven itself in the 90s as well, so its not like this was unknown when they designed EPIC.
      - kragen 4y ago
        otoh, for the previous 20 years, things like the 432 and lispms and burroughs large systems had been losing, in favor of architectures that pushed all the hard work onto compilers so it makes sense that in 01995 you'd look at ooo and vliw and extrapolate that vliw/epic was going to beat the crap out of ooo
        panick21_ 4y ago
        Granted it makes some amount of sense. But the issue is that with EPIC you still can address every part of the processor unless you want to continue to grow the instruction. So you end up having to do OoO anyway but you just made it much more complex and hard to reason about. I'm not a chip designer but is what I understood to be one of the issues. Also if this compiler stuff wasn't jet written, unlike with RISC where people at Standford showed successful compilation for RISC already before people even developed any high performance RISC chips. I don't want to claim I'm smarter then those people, clear all the people working on these VLIW processor were a lot smarter then me. But then again many smart people worked on Alpha and they didn't go the VLIW route.

ghaff 4y ago

One difference is that, according to the article, Intel actually learned quite a bit technically from the 432 even though it was a commercial flop. It's hard to see much of a silver lining in IA64/Itanium for either Intel or HP--or, indeed, for all the other companies that wasted resources on Itanium if only because they felt they had to cover their bases.

l1k 4y ago
A lot of RISC CPU arches which were popular in the 1990's declined because their promulgators stopped investments and bet on switching to IA64 instead. Around the year 2000, VLIW was seen as the future and all the CISC and RISC architectures were considered obsolete. That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium.
- ghaff 4y ago
  It's more complicated than that. Sun didn't slow down on UltraSPARC or make an Itanium side bet. IBM did (and continues to) place their big hardware bet on Power--Itanium was mostly a cover your bases thing. I don't know what HP would have done--presumably either gone their own way with VLIW or kept PA-RISC going. Pretty much all the other RISC/Unix players had to go to a standard processor; some were already on x86. Intel mostly recovered from Itanium specifically but it didn't do them any favors.
  - panick21_ 4y ago
    Sun didn't slow down on UltraSPARC but they were just not very good at designing processors.
  - sliken 4y ago
    Actually, they did. Intel promised aggressive delivery schedule, performance ramp, and performance. The industry took it hook, line, and sinker. While AMD decided not to limit 64 bit to the high end and brought out x86-64. Sun did a port IA64 port of solaris, which is definitely an itanium side bet. HP was involved in the IA64 effort and definitely was planning on the replacement of pa-risc from day 1.
    - davidgay 4y ago
      > HP was involved in the IA64 effort and definitely was planning on the replacement of pa-risc from day 1. As my memory remembers and https://en.wikipedia.org/wiki/Itanium https://en.wikipedia.org/wiki/Itanium agrees, Itanium originated at HP. So yes, a replacement for pa-risc from day 1, but even more so...
      - rodgerd 4y ago
        Another way to look at the Itanic is that HP somehow conned Intel into betting the farm on building HP-PA3 for HP. Which is pretty impressive.
- Dalewyn 4y ago
  >That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium. In that sense, Itanium was a resounding success for Intel (and AMD).
  - panick21_ 4y ago
    Itanium was a success right until they actually made a chip. What they should have done is hype Itanium and then they day it came out they should have said yeah this was a joke, what we did is buy Alpha from Compaq and its literally just Alpha with x86 comparability mode. Then they would have dominated.
- foobiekr 4y ago
  This isn't really true. IBM/Motorola need to own the failure of POWER and PowerPC and MIPS straight up died on the performance side. Sun continued with Ultrasparc. It wasn't that IA64 killed them, it's that they were getting shaky and IA64 appealed _because_ of that. Plus the lack of a 64bit x86.
  - panick21_ 4y ago
    Its simply economics Intel had the volume. Sun and SGI simply didn't have the economics to invest the same amount, and they were also not chip company, the both didn't invest enough in chip design or invested it wrongly. Sun spend an unbelievable amount of money on dumb ass processor projects. Towards the end of the 90s all of them realized their business model would not do well against Intel, so pretty much all of them were looking for an exit and IA64 hype basically killed most of them. Sun stuck it out with Sparc with mixed results. IBM POWER continues but in a thin slice of the market. Ironically there was a section of Digital and Intel who thought that Alpha should be the bases of 64 bit x86. That would have made Intel pretty dominate. Alpha (maybe a TSO version) with 32 bit x86 comparability mode.
    - PAPPPmAc 4y ago
      Look closely at AMD designs (and staff) of the very late 90s and early 2000s and/or all modern x86 parts and see that ...more or less, that's what happened, just not with an Alpha mode. Dirk Meyer (Co-Architect of the DEC Alpha 21064 and 21264) lead the K7 (Athlon) project, and they run on a licensed EV6 bus borrowed from the Alpha. Jim Keller (Co-Architect of the DEC Alpha 21164 21264) lead the K8 (first gen x86-64) project, and there are a number of design decisions in the K8 evocative of the later Alpha designs. The vast majority of x86 parts since the (NexGen Nx686 which became) AMD K6 and Pentium Pro (P6) have been internal RISC-ish cores with decoders that ingest x86 instructions and chunk them up to be scheduled on an internal RISC architecture. It has turned out to sort of be a better-than-both-worlds thing almost by accident. A major part of what did in the VLIW-ish designs was that "You can't statically schedule dynamic behavior" and a major problem for the RISC designs was that exposing architectural innovations on a RISC requires you change the ISA and/or memory behavior in visible ways from generation to generation, interfering with compatability so... the RISC-behind-x86-decoder designs get to follow the state of the art changing whatever they need to behind the decoder without breaking compatibility AND get to have the decoder do the micro-scheduling dynamically.
_0w8t 4y ago
Itanic was a flop due to AMD releasing 64bit CPU. And I still think Intel learned a lot from its failure if not from the technology but business-wise. Just stick to improving the existing architecture while keeping backward-compatibility.
- markhahn 4y ago
  VLIW was really marooned in time: driven by overconfidence in the compiler (which had shown that you could actually expose pipeline hazards), and underestimates of the coming abundance of transistors (which make superscalar OoO really take off, along with giant onchip caches). well, and multicore to sop up even more available transistors.
  - panick21_ 4y ago
    The problem is that VLIW has already proven not to work in the 90s with lots of companies investing money in it but not making it a product. EPIC was basically VLIW++ with lots of added stuff that should overcome the issues with it, but not doing that successfully. I don't think they underestimated the amount of transistors, they just thought that EPIC would be a better way to use them. OoO had already proven itself in the 90s as well, so its not like this was unknown when they designed EPIC.
    - kragen 4y ago
      otoh, for the previous 20 years, things like the 432 and lispms and burroughs large systems had been losing, in favor of architectures that pushed all the hard work onto compilers so it makes sense that in 01995 you'd look at ooo and vliw and extrapolate that vliw/epic was going to beat the crap out of ooo
      - panick21_ 4y ago
        Granted it makes some amount of sense. But the issue is that with EPIC you still can address every part of the processor unless you want to continue to grow the instruction. So you end up having to do OoO anyway but you just made it much more complex and hard to reason about. I'm not a chip designer but is what I understood to be one of the issues. Also if this compiler stuff wasn't jet written, unlike with RISC where people at Standford showed successful compilation for RISC already before people even developed any high performance RISC chips. I don't want to claim I'm smarter then those people, clear all the people working on these VLIW processor were a lot smarter then me. But then again many smart people worked on Alpha and they didn't go the VLIW route.