4 ms·

Yeah, IA64 was really exciting, until the hardware came out... Even the 'workstation' class machines were ridiculously loud and took a dedicated circuit to powe

Yeah, IA64 was really exciting, until the hardware came out... Even the 'workstation' class machines were ridiculously loud and took a dedicated circuit to power them. And the boot times, oh, the boot times. Then, the instruction set turned out to be all kinds of meh, and the optimizing compilers supposed to compensate for that never turned up. So, yeah, this was pretty much unavoidable. Even hardcore VAX holdouts (which HP eventually tried to capture, unsuccessfully) are on x64 by now...

mrweasel 4y ago
I've never been able to figure out if IA64 was poorly designed, or if the migration path was just to hard. The AMD64 seemed like a bit of a hack when it came out, but at the same time it was just a better solution for most. We had two Itanium servers for a project I worked on, both donated by HP. They weren't anything special, certainly didn't feel like an upgrade over our Sun machines.
- PreInternet01 4y ago
  Nah, it was just poorly designed. Intel promised two things for IA64: more instructions per clock and much higher clock rates. The first promise failed to materialize due to suitable compilers being much too difficult to implement, which in turn stopped investments in silicon improvements (which, in hindsight, would have been extremely challenging as well).
  - FullyFunctional 4y ago
    I'd offer a slightly modified take: - the promised compilers are _impossible_ as we can't predict all branches and all cache misses in _general_ (works better for floating point heavy code), - the failure to clock higher was IMO largely due to a ridiculously bloated and over-complicated ISA. In other words, EPIC was doomed from birth. I've written about IA-64 many times; it actually had many neat ideas, but in the end Intel yet again failed spectacularly in moving away from their archaic legacy.
    - peterfirefly 4y ago
      > the failure to clock higher was IMO largely due to a ridiculously bloated and over-complicated ISA. Perhaps mostly due to having too many architected registers AND making most of them rotating/part of register windows... that means more work to do per instruction. Wide superscalar => you need lots and lots of forwarding paths between the ALUs. Combined with no out of order execution to allow for spreading that work out a bit (longer latencies per instruction but largely hidden by other work) and you get hard limits on the clock speed. The ISA wasn't actually that bloated.
- adql 4y ago
  Both. It lived off an assumption that the magic compiler generating perfect assembly ideally fitting architecture will come out, and so CPU can skip the whole "crap" related to assigning incoming instruction stream to CPU's execution units. Which just didn't worked in practice. Current approach of CPU being basically an optimizing compiler that takes assembly in and generates uops to drive whatever execution units the CPU has might be wasteful silicon wise but... caches are much more transistors than this anyway and it allows CPU design to be separated from incoming assembly and so any improvements there are instantly visible to most existing code.
- jcranmer 4y ago
  IA64 is effectively a VLIW architecture, and... VLIW architectures just keep ending up not working out. There's a few things that make VLIW architectures hard to do well: * You're basically encoding microarchitectural details (which operations each execution port can run, how many execution ports, etc.) into the ISA, which makes changing that microachitecture difficult. (See also branch delay slots, which have a similar issue). * Several instructions have data-dependent execution time, and are very difficult to statically schedule. Dynamic scheduling can handle it much better. The common instruction classes are division, branches, and memory accesses, the latter two of which are among the most common instructions. * Static scheduling is limited by the inability to schedule around barriers, such as function calls. Dynamic scheduling can overlap in these scenarios. At the end of the day, the idea that you can rip out all of this fancy OoO-execution hardware and make it the compiler's problem just turns out worse than having the OoO hardware, with the smarter compiler having to manage the instruction stream to maximize the ability of the OoO hardware to get good performance.
  - ghaff 4y ago
    I'm finishing up writing a (very short) book on lessons from Itanium and I don't think I really appreciated all the VLIW backstory at the time. While I sort of understand why HP got excited about EPIC, I don't really understand how they got Intel to go along ESPECIALLY given that Intel had its i860 experience and could have presumably just maintained their market position with 64-bit x86 easy peasy.
    - hawflakes 4y ago
      Curious to read the book when it's out. I did work on some IA-64 software some time ago before Merced taped out so I'm interested!
  - msla 4y ago
    > You're basically encoding microarchitectural details (which operations each execution port can run, how many execution ports, etc.) into the ISA, which makes changing that microachitecture difficult. (See also branch delay slots, which have a similar issue). The HP/Intel people who designed the Itanium did have an answer for this one: Stop bits, which allow the software to indicate which opcodes can run in parallel even across words such that processors with more parallelism could run instructions from multiple words in parallel. Itanium was designed around EPIC, or Explicitly Parallel Instruction Computing, which was designed as a next-generation VLIW that took into account lessons learned from previous VLIW designs: https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio... > Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. Also: > Several instructions have data-dependent execution time, and are very difficult to statically schedule. Dynamic scheduling can handle it much better. They tried to handle this with prefetching and speculative loads, but, you're right, they didn't handle it well enough. > Static scheduling is limited by the inability to schedule around barriers, such as function calls. Dynamic scheduling can overlap in these scenarios. Itanium had speculative execution and delayed exceptions to try to get around this. Again, though, not good enough. Itanium was an interesting design, but it seems that VLIW plus modern superscalar techniques isn't as good as superscalar techniques alone.
- tyingq 4y ago
  It failed for the price/performance comparison to x64. Even if it performed 2x what it did, that still wouldn't have overcome the low commodity pricing for x64. Intel figured they had control over that by not releasing a 64-bit x86. AMD ruined that for Intel.
  - andix 4y ago
    Even without AMD intel would’ve needed to release cheap server, desktop and mobile 64 bit CPUs at some point, with reasonable compatibility to x86 code. It may have happened only around 2010 without AMDs pressure. Itanium could’ve never done the job for consumer grade or smaller servers. Too expensive, too exotic, and no possibility to run x86 code fast.
    - midoridensha 4y ago
      >Even without AMD intel would’ve needed to release cheap server, desktop and mobile 64 bit CPUs at some point, with reasonable compatibility to x86 code. I worked there at the time, and this was not the thinking in the company at all. The thinking was that if you needed 64-bit computing, you needed to buy an Itanium, full stop. Otherwise, 32 bits (with PAE) was all you needed. This is what Intel told all its customers. They really thought that IA64 was going to eventually replace x86 altogether.
      - andix 4y ago
        Yes, at that time Intel had the belief IA64 could be the new architecture. But do you think that plan had a chance to work out? I think it would've become clear after a few years, that IA64 was not a suitable platform to replace the complete CPU lineup. For example to replace the mobile Centrino CPUs with IA64. I think it would've failed in a similar way like Apple failed to put their G5 PPC into a laptop (and switched to Intel then). Or some pressure, because there is a strong business need to run new 64-bit code side-by-side with old x86 code (which is very slow on Itanium). And 32 bit + PAE might have been fine in 2000, but by 2010 the de-facto limit for 4GB memory space per process would've become a huge issue.
- bsder 4y ago
  When Intel announced that Itanium was going to be VLIW, the computer architects at DEC cheered. They knew full well from painful experience that VLIW was an absolute dead end. Of course, that was before the DEC Hostile Giveaway.

mrweasel 4y ago

I've never been able to figure out if IA64 was poorly designed, or if the migration path was just to hard. The AMD64 seemed like a bit of a hack when it came out, but at the same time it was just a better solution for most. We had two Itanium servers for a project I worked on, both donated by HP. They weren't anything special, certainly didn't feel like an upgrade over our Sun machines.

PreInternet01 4y ago
Nah, it was just poorly designed. Intel promised two things for IA64: more instructions per clock and much higher clock rates. The first promise failed to materialize due to suitable compilers being much too difficult to implement, which in turn stopped investments in silicon improvements (which, in hindsight, would have been extremely challenging as well).
- FullyFunctional 4y ago
  I'd offer a slightly modified take: - the promised compilers are _impossible_ as we can't predict all branches and all cache misses in _general_ (works better for floating point heavy code), - the failure to clock higher was IMO largely due to a ridiculously bloated and over-complicated ISA. In other words, EPIC was doomed from birth. I've written about IA-64 many times; it actually had many neat ideas, but in the end Intel yet again failed spectacularly in moving away from their archaic legacy.
  - peterfirefly 4y ago
    > the failure to clock higher was IMO largely due to a ridiculously bloated and over-complicated ISA. Perhaps mostly due to having too many architected registers AND making most of them rotating/part of register windows... that means more work to do per instruction. Wide superscalar => you need lots and lots of forwarding paths between the ALUs. Combined with no out of order execution to allow for spreading that work out a bit (longer latencies per instruction but largely hidden by other work) and you get hard limits on the clock speed. The ISA wasn't actually that bloated.
adql 4y ago
Both. It lived off an assumption that the magic compiler generating perfect assembly ideally fitting architecture will come out, and so CPU can skip the whole "crap" related to assigning incoming instruction stream to CPU's execution units. Which just didn't worked in practice. Current approach of CPU being basically an optimizing compiler that takes assembly in and generates uops to drive whatever execution units the CPU has might be wasteful silicon wise but... caches are much more transistors than this anyway and it allows CPU design to be separated from incoming assembly and so any improvements there are instantly visible to most existing code.
jcranmer 4y ago
IA64 is effectively a VLIW architecture, and... VLIW architectures just keep ending up not working out. There's a few things that make VLIW architectures hard to do well: * You're basically encoding microarchitectural details (which operations each execution port can run, how many execution ports, etc.) into the ISA, which makes changing that microachitecture difficult. (See also branch delay slots, which have a similar issue). * Several instructions have data-dependent execution time, and are very difficult to statically schedule. Dynamic scheduling can handle it much better. The common instruction classes are division, branches, and memory accesses, the latter two of which are among the most common instructions. * Static scheduling is limited by the inability to schedule around barriers, such as function calls. Dynamic scheduling can overlap in these scenarios. At the end of the day, the idea that you can rip out all of this fancy OoO-execution hardware and make it the compiler's problem just turns out worse than having the OoO hardware, with the smarter compiler having to manage the instruction stream to maximize the ability of the OoO hardware to get good performance.
- ghaff 4y ago
  I'm finishing up writing a (very short) book on lessons from Itanium and I don't think I really appreciated all the VLIW backstory at the time. While I sort of understand why HP got excited about EPIC, I don't really understand how they got Intel to go along ESPECIALLY given that Intel had its i860 experience and could have presumably just maintained their market position with 64-bit x86 easy peasy.
  - hawflakes 4y ago
    Curious to read the book when it's out. I did work on some IA-64 software some time ago before Merced taped out so I'm interested!
- msla 4y ago
  > You're basically encoding microarchitectural details (which operations each execution port can run, how many execution ports, etc.) into the ISA, which makes changing that microachitecture difficult. (See also branch delay slots, which have a similar issue). The HP/Intel people who designed the Itanium did have an answer for this one: Stop bits, which allow the software to indicate which opcodes can run in parallel even across words such that processors with more parallelism could run instructions from multiple words in parallel. Itanium was designed around EPIC, or Explicitly Parallel Instruction Computing, which was designed as a next-generation VLIW that took into account lessons learned from previous VLIW designs: https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio... > Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. Also: > Several instructions have data-dependent execution time, and are very difficult to statically schedule. Dynamic scheduling can handle it much better. They tried to handle this with prefetching and speculative loads, but, you're right, they didn't handle it well enough. > Static scheduling is limited by the inability to schedule around barriers, such as function calls. Dynamic scheduling can overlap in these scenarios. Itanium had speculative execution and delayed exceptions to try to get around this. Again, though, not good enough. Itanium was an interesting design, but it seems that VLIW plus modern superscalar techniques isn't as good as superscalar techniques alone.
tyingq 4y ago
It failed for the price/performance comparison to x64. Even if it performed 2x what it did, that still wouldn't have overcome the low commodity pricing for x64. Intel figured they had control over that by not releasing a 64-bit x86. AMD ruined that for Intel.
- andix 4y ago
  Even without AMD intel would’ve needed to release cheap server, desktop and mobile 64 bit CPUs at some point, with reasonable compatibility to x86 code. It may have happened only around 2010 without AMDs pressure. Itanium could’ve never done the job for consumer grade or smaller servers. Too expensive, too exotic, and no possibility to run x86 code fast.
  - midoridensha 4y ago
    >Even without AMD intel would’ve needed to release cheap server, desktop and mobile 64 bit CPUs at some point, with reasonable compatibility to x86 code. I worked there at the time, and this was not the thinking in the company at all. The thinking was that if you needed 64-bit computing, you needed to buy an Itanium, full stop. Otherwise, 32 bits (with PAE) was all you needed. This is what Intel told all its customers. They really thought that IA64 was going to eventually replace x86 altogether.
    - andix 4y ago
      Yes, at that time Intel had the belief IA64 could be the new architecture. But do you think that plan had a chance to work out? I think it would've become clear after a few years, that IA64 was not a suitable platform to replace the complete CPU lineup. For example to replace the mobile Centrino CPUs with IA64. I think it would've failed in a similar way like Apple failed to put their G5 PPC into a laptop (and switched to Intel then). Or some pressure, because there is a strong business need to run new 64-bit code side-by-side with old x86 code (which is very slow on Itanium). And 32 bit + PAE might have been fine in 2000, but by 2010 the de-facto limit for 4GB memory space per process would've become a huge issue.
bsder 4y ago
When Intel announced that Itanium was going to be VLIW, the computer architects at DEC cheered. They knew full well from painful experience that VLIW was an absolute dead end. Of course, that was before the DEC Hostile Giveaway.