10 ms·

Intel releases the last Itanium chip, the 9700

93 points by bhouston 10y ago

userbinator 10y ago
The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be anything other than NOPs, effectively making each instruction a ridiculously-cache-bloating 16 bytes long. I suppose a similar analogy would be doing everything in x86 with SIMD instructions and not using the scalar set at all.
- KenoFischer 10y ago
  > I suppose a similar analogy would be doing everything in x86 with SIMD instructions and not using the scalar set at all. With ever wider SIMD units this is actually happening to some extent. With AVX512 (e.g. on KNL) you can do 64 operations (single precision FLOPs) in vector units in the same amount of time as you can do 1 scalar operation. Combined with the low clock speed of the KNL, you really don't want to be doing scalar operations if you care at all about performance. Of course SIMD isn't the same as VLIW, since the operation you're doing has to be the same in all vector lanes, but with masking support in AVX512, it is getting a little closer to that. Also compilers have gotten quite a bit smarter and with hardware die shrinks taking longer, I wouldn't be at all surprised if VLIW ISAs were to make a comeback. I guess the Itanium was a bit ahead of its time.
  - deepnotderp 10y ago
    This, recent compiler advances in the past two decades have actually made VLIW somewhat tractable, but since the memory hierarchy and data movement wall consumes most of the power nowadays, the benefits of VLIW are mitigated.
    - dom0 10y ago
      Even if that were so, things are moving away from VLIW. E.g. AMD switched from VLIW to a more standard load-store SIMT approach a couple years ago, and even though it's more complex for the GPU, it increased system efficiency (esp. for workloads that their compiler was not well tuned for).
    - CalChris 10y ago
      Trace scheduling started with Fisher 81 [1] and Ellis 85 [2]. Trace scheduling is what made VLIW even possible if not exactly tractable. That was 30+ years ago. What recent advances have made VLIW any more tractable than trace scheduling already did? BTW, trace scheduling works for scheduling superscalar processors as well. VLIW never went away. It's used in embedded, the TriMedia processors. It's used in the REX Computing NEO chip. The Mill CPU is a VLIW of sorts. I'm not anti-VLIW but I don't know of any recent breakthroughs that make it any more tractable now for non-embedded, non-HPC general purpose computing. [1] Trace Scheduling: A Technique for Global Microcode Compaction https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d30932d7d8f4a933.pdf https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d3... [2] Bulldog: a compiler for VLIW architectures http://dl.acm.org/citation.cfm?id=912347 http://dl.acm.org/citation.cfm?id=912347
      - trsohmers 10y ago
        Designer of the Neo here, and owner of the California "VLIW" license plate. As you can guess, I am a die hard VLIW advocate, and a strong believer that the original promises of VLIW (Drastically simpler decode logic, implicit instruction level parallelism, virtually no control/data hazards on chip). VLIW has gotten an extremely bad rap outside of the embedded space due to Itanium, which I strongly contend was not a VLIW in spirit (which you cans see me talk in more depth on here: https://youtu.be/ki6jVXZM2XU?t=441 https://youtu.be/ki6jVXZM2XU?t=441). Itanium introduced a ton of indeterminism by having static scheduling unfriendly things like branch prediction, variable latency caches, and still trying to have some level of support for x86. The core problem for Itanium is that it was impossible for the compiler to make good decisions in the vast majority of applications since the compiler could not know exactly where and when things in memory would be. I believe the underlying failure point has been computer architects for failed VLIW architectures not realizing that fancy bells and whistles and "cleverly complex" hardware designs is the exact opposite of what you want when the compiler needs to be able to do purely static allocation. Adding fancy dynamic pieces in hardware to account from this (seen in a lot of places with Itanium) just makes the problem worse. The main improvement we have made with the Neo architecture is we have hard (exact cycle count) guarantees on all memory movements on and off the chip, which actually gives the compiler the information it needs to make good decisions and very condensed code. I think the jury is out on the applicability for "general purpose" code on VLIWs... it is not something we at REX really care about at the moment, and I think RISC-V is a great solution with improvements over x86 and ARM.
  - userbinator 10y ago
    With ever wider SIMD units this is actually happening to some extent. With AVX512 (e.g. on KNL) you can do 64 operations (single precision FLOPs) in vector units in the same amount of time as you can do 1 scalar operation I was talking about code which simply can't be parallelised because it is branchy or has long and unavoidable dependency chains. In those cases using SIMD instructions will only make the code larger (thus more cache-consuming) and arguably more power-consuming too, since 63/64 of those operations aren't contributing anything to the computation.
    - KenoFischer 10y ago
      Yes, I understand. What I meant was that you don't want to be running those kinds of codes on a KNL, because the performance is absolutely terrible. Nevertheless, Intel is producing the KNL, so there's now a market for this kind of thing, which may not have been there 15 years ago.
  - CyberDildonics 10y ago
    Actually it is 16 floating point operations in one AVX512 instruction and each core has two units, making 32 flops if you are running two or more threads (each core can do 4 way SMT but can also only decode two instructions per cycle).
    - KenoFischer 10y ago
      I was counting FMA as 2 operations ;).
      - CyberDildonics 10y ago
        That's Intel marketing and is somewhere between deceptive and wrong. Intel uses that to claim inflated maximum flops, with the huge aside that you would have to be doing nothing but fused multiply add, which is absurd.
        jabl 10y ago
        AFAICS everybody has been doing that long before Intel, so in their defense they're just following precedent. But yes, outside of carefully tuned kernels (e.g. GEMM and FFT), you're not going to see a 2x speedup. But that's no different from many other ISA extensions.
- ghaff 10y ago
  ILP specifically which, as it turned out was largely giving way to TLP in any case. I started writing a lesson from Itanium piece a while back. Maybe I should dust it off. (I followed Itanium pretty closely for a long time while I was an analyst.)
- deepnotderp 10y ago
  Your sequential CPUs are also exploiting parallelism to go faster, OoO execution, VLIW just wanted to do that in the compiler. There was nothing inherently wrong with the idea, the folly of Itanium was not the focus on parallelism, it was that compiler technology was not sufficiently advanced.
  - DannyBee 10y ago
    It's not even that, it's "common programming languages and programming paradigms do not always enable you to exploit this". IE if everyone is writing sequential C++, making a chip that is really good for parallel fortran is .... silly. No amount of compiler advance would have saved itanium. Research early on shows except for very contrived kernels, there wasn't enough ILP to extract. It actually did a really good job of doing what it could :)
  - userbinator 10y ago
    The overhead of padding 2/3 possible instructions with NOPs doesn't happen with "sequential CPUs". They extract parallelism only when and if it occurs. Even the most "sufficiently advanced" compiler can't parallelise everything.
  - acdha 10y ago
    I think there's a strong argument that it wasn't just that the compiler technology was insufficiently god-like but also that they over-estimated the degree to which instruction-level parallelism mattered to the general market. The quote below really fits my memory of the initial experience — the claims were really ambitious but even if it'd on-time (i.e. 2+ years earlier) and at the originally promised clock rates the results wouldn't have been especially impressive outside of a few fields like scientific computing. Even in HPC it was a question of how much time you were willing to spend hand-tuning every hot section. When it finally did ship, we got access to a dev system and found the Itanium systems generally struggled to surpass the previous generation systems which we were preparing to replace. “Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis.” The rest of this PDF is well worth reading: http://courses.cs.washington.edu/courses/csep590/06au/projects/history-64-bit.pdf http://courses.cs.washington.edu/courses/csep590/06au/projec...
- DannyBee 10y ago
  "The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. " Well no, it would be more accurate to say "a noteworthy example of when you release a chip that isn't in line with what common programming languages can do". That is, there is nothing wrong with doing the above. There's something wrong with doing the above when you most people are writing sequential C++ :) There simply wasn't enough ILP to extract :) IE no amount of compiler advance would have saved it.
  - chrisseaton 10y ago
    But conventional Intel processors do manage to dynamically extract quite a good deal of ILP don't they? That's been the source of most of our performance increases over the last decade I think. Why does it work dynamically but not statically?
    - DannyBee 10y ago
      They can extract some ILP, but most of that is because it has no limitations but the semantics of the instruction set. It also cheats and can speculate just about everything legally, because it can always undo it. A large amount of the ILP is, AFAIK, from being able to prefetch accurately (IE guess what memory will be accessed) and guess branch directions correctly. This is not possible to do as well statically. You actually can do it well dynamically (IE i could make a branch guessing thread and a prefetching thread), but you can't do it fast enough. In a lot of workloads, most time is spent stalling for memory. Also note that in VLIW, you have to extract ILP or you are just wasting time (IE are executing NOPs). You end up with a half or 3/4 empty pipeline. So unless you can predict you are going to stall for memory well, you are wasting the pipeline. On the other hand, modern OOO cores can just extract more ILP when possible. IE when stalling for memory, they can figure out what they could be doing otherwise.
      - chrisseaton 10y ago
        Maybe it's like JITs vs static compilers - we're better off with JIT even if your language is static, because you can adapt to real runtime conditions.
- CalChris 10y ago
  leaves all instruction scheduling to the compiler In-order processors also leave instruction scheduling to the compiler. They're very common. The workhorse ARM Cortex-A7 is in-order, dual issue and pipelined.
deleted 10y ago
[deleted]
tyingq 10y ago
We would probably all be working with Itanium servers if not for AMD introducing 64 bit x86. I believe that also accelerated Linux adoption and the decline of all the commercial Unix platforms. Good to see AMD on the rise again. I appreciate their role in heading off Itanium.
- bluedino 10y ago
  What makes you think it wouldn't have been POWER? Or SPARC? They were both way more popular than PA-RISC.
  - tyingq 10y ago
    Because Power and Sparc would have ceded to Itanium. Neither backer had the resources Intel did. The easy path to kill Itanium was x86-64, because it was inexpensive and worked with Linux and Windows. AMD didn't have to compete with Intel per se. It forced Intel to do X86-64 as well...which killed Itanium.
- bluejekyll 10y ago
  Had x86_64 not been released, I also think we'd see a more diverse set of serverside chips as well, such as SPARC and POWER. There wouldn't have been an obvious dominance in the marketplace of a single architecture. Also, had it not been released, we'd probably have seen a larger fracturing of the laptop CPU market with a broader switch to ARM64. In a sense, because AMD forced Intel's hand in supporting x86_64, they actually helped Intel have even more dominance in the market with an architecture that spans laptops to server work horses. We developers barely need to lift a finger in targeting either.
  - tyingq 10y ago
    I dunno. The cost advantage of x86-64 plus Linux and Windows was a tough nut for other RISC vendors to beat. Price/Performance, plus general support. For example, x86-64 servers could get away without SSL acceleration because the handshake was done in optimized ASM for most web servers. For other architectures, it wasn't.
sfifs 10y ago
Question seeking to understand - Why would anyone buy a tech component product that is explicitly called out as last of its kind?
- smacktoward 10y ago
  Because you've already sunk an enormous amount of money into the architecture, and you're looking to defer the day when you have to admit that was a bad idea for as long as humanly possible.
- deleted 10y ago
  [deleted]
- nickpsecurity 10y ago
  1. To keep your stuff running that's stuck on that chip. Replacements are being made but not finished for many customers. The article actually covers this for HP's customers. OpenVMS was on Itanium as well with a x86 port underway. SGI was on Itanium but moved to Xeon more quickly. 2. To get benefits that chip has that others don't. Secure64 is the main use-case I know for this. For me, I considered buying some SGI Altix's off ebay that were going for $100-200 each. Reliable chip and server with built-in security features that almost nobody is targeting on top of that. Such an approach has always paid off for me in the past. https://secure64.com/secure-operating-system/ https://secure64.com/secure-operating-system/
my123 10y ago
32nm chip in 2017, probably to reduce costs.
bogomipz 10y ago
From the article: >"Intel can now focus on Xeon, which was rebranded last week to account for new technologies like co-processors and faster interconnects." I was confused by this, Xeon has been the mainstay in the high-end workstation/server for what feels like forever now. Was the limited Itanium market and development really affecting their focus that much? I am curious if anyone knows what companies or verticals made big investments in Itanium? I imagining Intel much have some pretty big Itanium customers if it has been around this long. Maybe this answers my first question?
- zargon 10y ago
  Xeon wasn't losing focus to Itanium... that's just the author writing filler material. The main customer of Itanium that I'm aware of is the VMS operating system. It was ported from Alpha to Itanium in the early days of Itanium and anyone dependent on VMS has been reliant on Itanium since then. HP paid Intel a few years ago not to kill Itanium in the meantime while they were porting VMS to x86.
  - bogomipz 10y ago
    Oh interesting, I did not know that. I have heard that the US government has a lot of VMS systems. If that's true then this alone would make sense for HP to fund Itanium to some extent.
trentnelson 10y ago
Related: excellent article on IA64/x64 etc: https://github.com/tpn/pdfs/blob/master/A%20History%20of%20Modern%2064-bit%20Computing%20-%20Feb%202007%20(CSEP590A).pdf https://github.com/tpn/pdfs/blob/master/A%20History%20of%20M... Features quotes from various interviews with folks like David Cutler. Fascinating (and not surprising) to connect the dots between the NT x64 calling conventions + SEH + RIP-relative addressing and Dave Cutler's initial input. Regarding the Itanium itself, I've always found this excerpt quite interesting: "Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average systemwide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis." (Page 6 of cited PDF.)
- martinpw 10y ago
  > Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. At the time Itanium was actively being pushed by Intel I was working for a company building content creation software. Intel was very interested in us porting to Itanium and provided considerable help to that effort. One of the big reasons was that they were interested in being able to see the traces, precisely for the reason you state - most of their existing test code was not representative of typical large scale commercial software. We got it running but never released it - the binaries were huge (3x x86) which was a big issue back then, and the performance just wasn't there.
arnon 10y ago
I'm extremely surprised Intel was working on that at all. Probably retiring a bunch of CPU people as a result
ChuckMcM 10y ago
As an interesting data point, (and the article doesn't do it justice), when I saw the presentation on AMD's "Sledgehammer" architecture (the AMD64) at Microprocessor Forum I wrote to the CTO of NetApp at the time "If you're wondering, Itanium just died." And then more than 16 years later it actually is going to cease development. It also started a multi-year effort to convince NetApp to use an AMD chip in their filer :-). I think the events reinforce three good things to know; 1) Adapting the existing system to do new things can trump entirely new systems, even if those new systems are 'better' in some way. 2) You can change hardware "overnight for free" compared to how difficult it is to migrate large software systems. 3) "Eat your young" - Keep innovating in your own products, even if that means it makes previous versions obsolete, because if you don't your competitors will. So long Itanium.
- RcouF1uZ4gsC 10y ago
  I agree with your assessment. It seemed Intel tried to use the 32-bit limit of x86 to drive the high end computing to Itanium. AMD did x86-64 and removed that limit, and Intel was forced to play along and x86 escaped from its artificial limits and removed much of the justification for Itanium.
chx 10y ago
I much enjoyed http://www.pcmag.com/article2/0,2817,2339629,00.asp http://www.pcmag.com/article2/0,2817,2339629,00.asp this review of Itanium history.
faragon 10y ago
The Anandtech article is better [1], in my opinion. [1] http://www.anandtech.com/show/11372/intels-itanium-takes-one-last-breath-9700-series-released http://www.anandtech.com/show/11372/intels-itanium-takes-one...
jabl 10y ago
Oh dear, won't somebody think of Paul DeMone? Poor soul must be going through an existential crisis..

93 points by bhouston 10y ago

The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be anything other than NOPs, effectively making each instruction a ridiculously-cache-bloating 16 bytes long. I suppose a similar analogy would be doing everything in x86 with SIMD instructions and not using the scalar set at all.

KenoFischer 10y ago
> I suppose a similar analogy would be doing everything in x86 with SIMD instructions and not using the scalar set at all. With ever wider SIMD units this is actually happening to some extent. With AVX512 (e.g. on KNL) you can do 64 operations (single precision FLOPs) in vector units in the same amount of time as you can do 1 scalar operation. Combined with the low clock speed of the KNL, you really don't want to be doing scalar operations if you care at all about performance. Of course SIMD isn't the same as VLIW, since the operation you're doing has to be the same in all vector lanes, but with masking support in AVX512, it is getting a little closer to that. Also compilers have gotten quite a bit smarter and with hardware die shrinks taking longer, I wouldn't be at all surprised if VLIW ISAs were to make a comeback. I guess the Itanium was a bit ahead of its time.
- deepnotderp 10y ago
  This, recent compiler advances in the past two decades have actually made VLIW somewhat tractable, but since the memory hierarchy and data movement wall consumes most of the power nowadays, the benefits of VLIW are mitigated.
  - dom0 10y ago
    Even if that were so, things are moving away from VLIW. E.g. AMD switched from VLIW to a more standard load-store SIMT approach a couple years ago, and even though it's more complex for the GPU, it increased system efficiency (esp. for workloads that their compiler was not well tuned for).
  - CalChris 10y ago
    Trace scheduling started with Fisher 81 [1] and Ellis 85 [2]. Trace scheduling is what made VLIW even possible if not exactly tractable. That was 30+ years ago. What recent advances have made VLIW any more tractable than trace scheduling already did? BTW, trace scheduling works for scheduling superscalar processors as well. VLIW never went away. It's used in embedded, the TriMedia processors. It's used in the REX Computing NEO chip. The Mill CPU is a VLIW of sorts. I'm not anti-VLIW but I don't know of any recent breakthroughs that make it any more tractable now for non-embedded, non-HPC general purpose computing. [1] Trace Scheduling: A Technique for Global Microcode Compaction https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d30932d7d8f4a933.pdf https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d3... [2] Bulldog: a compiler for VLIW architectures http://dl.acm.org/citation.cfm?id=912347 http://dl.acm.org/citation.cfm?id=912347
    - trsohmers 10y ago
      Designer of the Neo here, and owner of the California "VLIW" license plate. As you can guess, I am a die hard VLIW advocate, and a strong believer that the original promises of VLIW (Drastically simpler decode logic, implicit instruction level parallelism, virtually no control/data hazards on chip). VLIW has gotten an extremely bad rap outside of the embedded space due to Itanium, which I strongly contend was not a VLIW in spirit (which you cans see me talk in more depth on here: https://youtu.be/ki6jVXZM2XU?t=441 https://youtu.be/ki6jVXZM2XU?t=441). Itanium introduced a ton of indeterminism by having static scheduling unfriendly things like branch prediction, variable latency caches, and still trying to have some level of support for x86. The core problem for Itanium is that it was impossible for the compiler to make good decisions in the vast majority of applications since the compiler could not know exactly where and when things in memory would be. I believe the underlying failure point has been computer architects for failed VLIW architectures not realizing that fancy bells and whistles and "cleverly complex" hardware designs is the exact opposite of what you want when the compiler needs to be able to do purely static allocation. Adding fancy dynamic pieces in hardware to account from this (seen in a lot of places with Itanium) just makes the problem worse. The main improvement we have made with the Neo architecture is we have hard (exact cycle count) guarantees on all memory movements on and off the chip, which actually gives the compiler the information it needs to make good decisions and very condensed code. I think the jury is out on the applicability for "general purpose" code on VLIWs... it is not something we at REX really care about at the moment, and I think RISC-V is a great solution with improvements over x86 and ARM.
- userbinator 10y ago
  With ever wider SIMD units this is actually happening to some extent. With AVX512 (e.g. on KNL) you can do 64 operations (single precision FLOPs) in vector units in the same amount of time as you can do 1 scalar operation I was talking about code which simply can't be parallelised because it is branchy or has long and unavoidable dependency chains. In those cases using SIMD instructions will only make the code larger (thus more cache-consuming) and arguably more power-consuming too, since 63/64 of those operations aren't contributing anything to the computation.
  - KenoFischer 10y ago
    Yes, I understand. What I meant was that you don't want to be running those kinds of codes on a KNL, because the performance is absolutely terrible. Nevertheless, Intel is producing the KNL, so there's now a market for this kind of thing, which may not have been there 15 years ago.
- CyberDildonics 10y ago
  Actually it is 16 floating point operations in one AVX512 instruction and each core has two units, making 32 flops if you are running two or more threads (each core can do 4 way SMT but can also only decode two instructions per cycle).
  - KenoFischer 10y ago
    I was counting FMA as 2 operations ;).
    - CyberDildonics 10y ago
      That's Intel marketing and is somewhere between deceptive and wrong. Intel uses that to claim inflated maximum flops, with the huge aside that you would have to be doing nothing but fused multiply add, which is absurd.
      - jabl 10y ago
        AFAICS everybody has been doing that long before Intel, so in their defense they're just following precedent. But yes, outside of carefully tuned kernels (e.g. GEMM and FFT), you're not going to see a 2x speedup. But that's no different from many other ISA extensions.
ghaff 10y ago
ILP specifically which, as it turned out was largely giving way to TLP in any case. I started writing a lesson from Itanium piece a while back. Maybe I should dust it off. (I followed Itanium pretty closely for a long time while I was an analyst.)
deepnotderp 10y ago
Your sequential CPUs are also exploiting parallelism to go faster, OoO execution, VLIW just wanted to do that in the compiler. There was nothing inherently wrong with the idea, the folly of Itanium was not the focus on parallelism, it was that compiler technology was not sufficiently advanced.
- DannyBee 10y ago
  It's not even that, it's "common programming languages and programming paradigms do not always enable you to exploit this". IE if everyone is writing sequential C++, making a chip that is really good for parallel fortran is .... silly. No amount of compiler advance would have saved itanium. Research early on shows except for very contrived kernels, there wasn't enough ILP to extract. It actually did a really good job of doing what it could :)
- userbinator 10y ago
  The overhead of padding 2/3 possible instructions with NOPs doesn't happen with "sequential CPUs". They extract parallelism only when and if it occurs. Even the most "sufficiently advanced" compiler can't parallelise everything.
- acdha 10y ago
  I think there's a strong argument that it wasn't just that the compiler technology was insufficiently god-like but also that they over-estimated the degree to which instruction-level parallelism mattered to the general market. The quote below really fits my memory of the initial experience — the claims were really ambitious but even if it'd on-time (i.e. 2+ years earlier) and at the originally promised clock rates the results wouldn't have been especially impressive outside of a few fields like scientific computing. Even in HPC it was a question of how much time you were willing to spend hand-tuning every hot section. When it finally did ship, we got access to a dev system and found the Itanium systems generally struggled to surpass the previous generation systems which we were preparing to replace. “Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis.” The rest of this PDF is well worth reading: http://courses.cs.washington.edu/courses/csep590/06au/projects/history-64-bit.pdf http://courses.cs.washington.edu/courses/csep590/06au/projec...
DannyBee 10y ago
"The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. " Well no, it would be more accurate to say "a noteworthy example of when you release a chip that isn't in line with what common programming languages can do". That is, there is nothing wrong with doing the above. There's something wrong with doing the above when you most people are writing sequential C++ :) There simply wasn't enough ILP to extract :) IE no amount of compiler advance would have saved it.
- chrisseaton 10y ago
  But conventional Intel processors do manage to dynamically extract quite a good deal of ILP don't they? That's been the source of most of our performance increases over the last decade I think. Why does it work dynamically but not statically?
  - DannyBee 10y ago
    They can extract some ILP, but most of that is because it has no limitations but the semantics of the instruction set. It also cheats and can speculate just about everything legally, because it can always undo it. A large amount of the ILP is, AFAIK, from being able to prefetch accurately (IE guess what memory will be accessed) and guess branch directions correctly. This is not possible to do as well statically. You actually can do it well dynamically (IE i could make a branch guessing thread and a prefetching thread), but you can't do it fast enough. In a lot of workloads, most time is spent stalling for memory. Also note that in VLIW, you have to extract ILP or you are just wasting time (IE are executing NOPs). You end up with a half or 3/4 empty pipeline. So unless you can predict you are going to stall for memory well, you are wasting the pipeline. On the other hand, modern OOO cores can just extract more ILP when possible. IE when stalling for memory, they can figure out what they could be doing otherwise.
    - chrisseaton 10y ago
      Maybe it's like JITs vs static compilers - we're better off with JIT even if your language is static, because you can adapt to real runtime conditions.
CalChris 10y ago
leaves all instruction scheduling to the compiler In-order processors also leave instruction scheduling to the compiler. They're very common. The workhorse ARM Cortex-A7 is in-order, dual issue and pipelined.

deleted 10y ago

[deleted]

tyingq 10y ago

We would probably all be working with Itanium servers if not for AMD introducing 64 bit x86. I believe that also accelerated Linux adoption and the decline of all the commercial Unix platforms. Good to see AMD on the rise again. I appreciate their role in heading off Itanium.

bluedino 10y ago
What makes you think it wouldn't have been POWER? Or SPARC? They were both way more popular than PA-RISC.
- tyingq 10y ago
  Because Power and Sparc would have ceded to Itanium. Neither backer had the resources Intel did. The easy path to kill Itanium was x86-64, because it was inexpensive and worked with Linux and Windows. AMD didn't have to compete with Intel per se. It forced Intel to do X86-64 as well...which killed Itanium.
bluejekyll 10y ago
Had x86_64 not been released, I also think we'd see a more diverse set of serverside chips as well, such as SPARC and POWER. There wouldn't have been an obvious dominance in the marketplace of a single architecture. Also, had it not been released, we'd probably have seen a larger fracturing of the laptop CPU market with a broader switch to ARM64. In a sense, because AMD forced Intel's hand in supporting x86_64, they actually helped Intel have even more dominance in the market with an architecture that spans laptops to server work horses. We developers barely need to lift a finger in targeting either.
- tyingq 10y ago
  I dunno. The cost advantage of x86-64 plus Linux and Windows was a tough nut for other RISC vendors to beat. Price/Performance, plus general support. For example, x86-64 servers could get away without SSL acceleration because the handshake was done in optimized ASM for most web servers. For other architectures, it wasn't.

sfifs 10y ago

Question seeking to understand - Why would anyone buy a tech component product that is explicitly called out as last of its kind?

smacktoward 10y ago
Because you've already sunk an enormous amount of money into the architecture, and you're looking to defer the day when you have to admit that was a bad idea for as long as humanly possible.
deleted 10y ago
[deleted]
nickpsecurity 10y ago
1. To keep your stuff running that's stuck on that chip. Replacements are being made but not finished for many customers. The article actually covers this for HP's customers. OpenVMS was on Itanium as well with a x86 port underway. SGI was on Itanium but moved to Xeon more quickly. 2. To get benefits that chip has that others don't. Secure64 is the main use-case I know for this. For me, I considered buying some SGI Altix's off ebay that were going for $100-200 each. Reliable chip and server with built-in security features that almost nobody is targeting on top of that. Such an approach has always paid off for me in the past. https://secure64.com/secure-operating-system/ https://secure64.com/secure-operating-system/

my123 10y ago

32nm chip in 2017, probably to reduce costs.

bogomipz 10y ago

From the article: >"Intel can now focus on Xeon, which was rebranded last week to account for new technologies like co-processors and faster interconnects." I was confused by this, Xeon has been the mainstay in the high-end workstation/server for what feels like forever now. Was the limited Itanium market and development really affecting their focus that much? I am curious if anyone knows what companies or verticals made big investments in Itanium? I imagining Intel much have some pretty big Itanium customers if it has been around this long. Maybe this answers my first question?

zargon 10y ago
Xeon wasn't losing focus to Itanium... that's just the author writing filler material. The main customer of Itanium that I'm aware of is the VMS operating system. It was ported from Alpha to Itanium in the early days of Itanium and anyone dependent on VMS has been reliant on Itanium since then. HP paid Intel a few years ago not to kill Itanium in the meantime while they were porting VMS to x86.
- bogomipz 10y ago
  Oh interesting, I did not know that. I have heard that the US government has a lot of VMS systems. If that's true then this alone would make sense for HP to fund Itanium to some extent.

trentnelson 10y ago

Related: excellent article on IA64/x64 etc: https://github.com/tpn/pdfs/blob/master/A%20History%20of%20Modern%2064-bit%20Computing%20-%20Feb%202007%20(CSEP590A).pdf https://github.com/tpn/pdfs/blob/master/A%20History%20of%20M... Features quotes from various interviews with folks like David Cutler. Fascinating (and not surprising) to connect the dots between the NT x64 calling conventions + SEH + RIP-relative addressing and Dave Cutler's initial input. Regarding the Itanium itself, I've always found this excerpt quite interesting: "Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average systemwide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis." (Page 6 of cited PDF.)

martinpw 10y ago
> Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. At the time Itanium was actively being pushed by Intel I was working for a company building content creation software. Intel was very interested in us porting to Itanium and provided considerable help to that effort. One of the big reasons was that they were interested in being able to see the traces, precisely for the reason you state - most of their existing test code was not representative of typical large scale commercial software. We got it running but never released it - the binaries were huge (3x x86) which was a big issue back then, and the performance just wasn't there.

arnon 10y ago

I'm extremely surprised Intel was working on that at all. Probably retiring a bunch of CPU people as a result

ChuckMcM 10y ago

As an interesting data point, (and the article doesn't do it justice), when I saw the presentation on AMD's "Sledgehammer" architecture (the AMD64) at Microprocessor Forum I wrote to the CTO of NetApp at the time "If you're wondering, Itanium just died." And then more than 16 years later it actually is going to cease development. It also started a multi-year effort to convince NetApp to use an AMD chip in their filer :-). I think the events reinforce three good things to know; 1) Adapting the existing system to do new things can trump entirely new systems, even if those new systems are 'better' in some way. 2) You can change hardware "overnight for free" compared to how difficult it is to migrate large software systems. 3) "Eat your young" - Keep innovating in your own products, even if that means it makes previous versions obsolete, because if you don't your competitors will. So long Itanium.

RcouF1uZ4gsC 10y ago
I agree with your assessment. It seemed Intel tried to use the 32-bit limit of x86 to drive the high end computing to Itanium. AMD did x86-64 and removed that limit, and Intel was forced to play along and x86 escaped from its artificial limits and removed much of the justification for Itanium.

chx 10y ago

I much enjoyed http://www.pcmag.com/article2/0,2817,2339629,00.asp http://www.pcmag.com/article2/0,2817,2339629,00.asp this review of Itanium history.

faragon 10y ago

The Anandtech article is better [1], in my opinion. [1] http://www.anandtech.com/show/11372/intels-itanium-takes-one-last-breath-9700-series-released http://www.anandtech.com/show/11372/intels-itanium-takes-one...

jabl 10y ago

Oh dear, won't somebody think of Paul DeMone? Poor soul must be going through an existential crisis..