6 ms·

Actually, Itanium died because the perf sucked. And it had no compat. So yeah...

dogma1138 10y ago
The performance didn't suck that much, not for the RISC part. The problem was that too many IA-64 application relied on the x86/xCPU emulation which was well yeah very shitty.
- qwertyuiop924 10y ago
  Ah...
- userbinator 10y ago
  The Itanium is a VLIW, not a RISC (although they have some similarities). It executes "bundles" of 3 instructions in parallel. It was excellent in certain benchmarks because the compiler could schedule sequences to make full use of this; but it turns out that general-purpose code isn't really so parallel all the time, so the compiler would have to fill 2 or 3 of the slots in each bundle with NOPs, wasting space (thus cache usage and fetch bandwidth) and leave much of the CPU's execution units idle. It was great at highly parallel benchmarks, but much slower than contemporary x86 (the P4, which wasn't that great either) for everything else.
  - dogma1138 10y ago
    Yeah it was VLIW/EPIC but i like the puns :P As for the performance I don't have enough experience to pinpoint exactly all the problems, but i think it really ended up being a software issue. Most complaints I've encountered were about the "emulation" part with the dynamic translation libraries and instruction set emulation. Overall it seems to me like they just tried to tackle too many things, have some compatibility with X86, take on SPARC/POWERPC and do HPC, mainframes and tons of other applications at the same time. That said after all this is still a mid 90's ISA for a very niche market with all these issues its surprising it lasted so long, I never understood why HP kept paying Intel to produce these chips in the first place.
- acdha 10y ago
  The performance for native code wasn't bad but it was never the game-changer the early marketing pitch predicted and that was especially true compared with the competition after adjusting for price or power consumption. I used to work with a group of scientists who wanted as much performance as they eke out. They had a large C codebase which had already been ported to every major architecture and it did a ton of floating point math along with a fair amount of integer work, etc. — basically the best-case scenario for IA-64. Unfortunately, even with Intel's compiler and tuning tools the performance just never panned out: the best-case scenario was that if someone wanted to divert years of staff time into tuning, IA-64 might take the performance crown but that would be an expensive gamble and probably locking ourselves into a single server vendor (HP). It was much safer to simply take that time and money and buy x86-64 boxes which were faster and available from many vendors. (The same story repeated later with Cell: neat possibilities but nowhere near enough benefit to justify the risk of locking in to a single vendor architecture with an unclear future) Ignoring the architectural debates, Intel made two fatal implementation mistakes with IA-64: the most obvious one was never finding a deadline they couldn't miss but a less obvious problem was failing to take software, and particularly open-source software, seriously enough. IA-64 performance critically depended on using Intel's proprietary compilers. Since those were extremely expensive, almost nobody used them and thus they had compatibility issues with many large Unix or Windows codebases, and the focus was clearly on the optimizations needed to deliver good SPEC benchmark results rather than other features. I don't know how much difference it would have made in the end but I think having a solid open-source or at least free toolchain would have made it less expensive to try the platform. It's very easy to imagine that it would have gone considerably differently had something like LLVM existed back then and Intel had simply contributed a high-quality backend, not to mention having a broad general shell server program for open-source projects to use to port and optimize.
  - dogma1138 10y ago
    Itanium came out of a spec that HP initially designed, so it most likely had a lot of impact to do with it being locked to a single vendor (i think SGI played with Itanium workstations but my memory fails me at this point). I'm not defending IA-64 overall it had issues, but it wasn't as bad as some people claim it to be "OMG INTEL CAN'T DO X64 THEY SUCK". Intel also took quite a long time to bring Itanium CPU's to the forefront of Intel's own technology, Itanium got DDR3 and QPI only in 2010. By the time Intel brought all the good things to Itanium it was pretty much already dead in the water and on life support, but doesn't really bare on the viability of the IA-64 as an architecture it more or less bares on the viability of the Itanium as a product line.
- gaius 10y ago
  Everything promised about the Itanium relied on a "sufficiently smart compiler" which proved harder to write than anyone expected. It's being kept alive now solely because of legal agreements (e.g. see the recent HP vs Oracle case). Technologically it's a dead end, I don't think too many people dispute that in 2016. It's just a shame that it killed SGI.

The performance didn't suck that much, not for the RISC part. The problem was that too many IA-64 application relied on the x86/xCPU emulation which was well yeah very shitty.

qwertyuiop924 10y ago
Ah...
userbinator 10y ago
The Itanium is a VLIW, not a RISC (although they have some similarities). It executes "bundles" of 3 instructions in parallel. It was excellent in certain benchmarks because the compiler could schedule sequences to make full use of this; but it turns out that general-purpose code isn't really so parallel all the time, so the compiler would have to fill 2 or 3 of the slots in each bundle with NOPs, wasting space (thus cache usage and fetch bandwidth) and leave much of the CPU's execution units idle. It was great at highly parallel benchmarks, but much slower than contemporary x86 (the P4, which wasn't that great either) for everything else.
- dogma1138 10y ago
  Yeah it was VLIW/EPIC but i like the puns :P As for the performance I don't have enough experience to pinpoint exactly all the problems, but i think it really ended up being a software issue. Most complaints I've encountered were about the "emulation" part with the dynamic translation libraries and instruction set emulation. Overall it seems to me like they just tried to tackle too many things, have some compatibility with X86, take on SPARC/POWERPC and do HPC, mainframes and tons of other applications at the same time. That said after all this is still a mid 90's ISA for a very niche market with all these issues its surprising it lasted so long, I never understood why HP kept paying Intel to produce these chips in the first place.
acdha 10y ago
The performance for native code wasn't bad but it was never the game-changer the early marketing pitch predicted and that was especially true compared with the competition after adjusting for price or power consumption. I used to work with a group of scientists who wanted as much performance as they eke out. They had a large C codebase which had already been ported to every major architecture and it did a ton of floating point math along with a fair amount of integer work, etc. — basically the best-case scenario for IA-64. Unfortunately, even with Intel's compiler and tuning tools the performance just never panned out: the best-case scenario was that if someone wanted to divert years of staff time into tuning, IA-64 might take the performance crown but that would be an expensive gamble and probably locking ourselves into a single server vendor (HP). It was much safer to simply take that time and money and buy x86-64 boxes which were faster and available from many vendors. (The same story repeated later with Cell: neat possibilities but nowhere near enough benefit to justify the risk of locking in to a single vendor architecture with an unclear future) Ignoring the architectural debates, Intel made two fatal implementation mistakes with IA-64: the most obvious one was never finding a deadline they couldn't miss but a less obvious problem was failing to take software, and particularly open-source software, seriously enough. IA-64 performance critically depended on using Intel's proprietary compilers. Since those were extremely expensive, almost nobody used them and thus they had compatibility issues with many large Unix or Windows codebases, and the focus was clearly on the optimizations needed to deliver good SPEC benchmark results rather than other features. I don't know how much difference it would have made in the end but I think having a solid open-source or at least free toolchain would have made it less expensive to try the platform. It's very easy to imagine that it would have gone considerably differently had something like LLVM existed back then and Intel had simply contributed a high-quality backend, not to mention having a broad general shell server program for open-source projects to use to port and optimize.
- dogma1138 10y ago
  Itanium came out of a spec that HP initially designed, so it most likely had a lot of impact to do with it being locked to a single vendor (i think SGI played with Itanium workstations but my memory fails me at this point). I'm not defending IA-64 overall it had issues, but it wasn't as bad as some people claim it to be "OMG INTEL CAN'T DO X64 THEY SUCK". Intel also took quite a long time to bring Itanium CPU's to the forefront of Intel's own technology, Itanium got DDR3 and QPI only in 2010. By the time Intel brought all the good things to Itanium it was pretty much already dead in the water and on life support, but doesn't really bare on the viability of the IA-64 as an architecture it more or less bares on the viability of the Itanium as a product line.
gaius 10y ago
Everything promised about the Itanium relied on a "sufficiently smart compiler" which proved harder to write than anyone expected. It's being kept alive now solely because of legal agreements (e.g. see the recent HP vs Oracle case). Technologically it's a dead end, I don't think too many people dispute that in 2016. It's just a shame that it killed SGI.