One of Intel’s ventures into the historic mainframe space was Itanium: a 64-bit capable processor designed in conjunction with Hewlett Packard. The main reason for Itanium was to run HP-UX and compete against big names, such as Oracle, using a new IA-64 instruction set. The appeal for the original Itanium parts was support for RAS features, ECC, and cores focus on a wide, parallel architecture - the latest cores support 12-wide execution for example. For a short while, there was success: HP’s systems based on Itanium are advertised as high-uptime mission critical servers, and a number of customers cling to these systems like a child clings to their favorite blanket due to the way they are integrated at the core of the company. The main purpose was to compete against other mission critical servers and mainframes based on SPARC and IBM Power.

So when the processors were initially delivered to customers, there was potential. However the initial impression was not great - they consumed too much power, were noisy, and needed over the top cooling. Over the years and generations of Itanium, the march into the x86 enterprise space with x86-64 drew potential Itanium customers away, then followed the drop of Microsoft's support for Itanium in 2008, and Oracle's dropped support in 2011. Xeon offerings were becoming popular, with CPUs incorporating the RAS/ECC features required, and Intel decided to slow down Itanium development as a result. In the meantime, due to the way the market was moving, HP transitioned a good part of its product stack to Xeons. Despite this, legal battles between HP and Oracle ensued given predicted support for HP-UX customers. At this point, there were fewer potential Itanium customers each quarter, although existing customers required support.

Today marks the release of the final known variant of Itanium, the 9700 series, beyond assurance testing. Intel spoke to IDG, stating that this generation, code-named Kittson, would be the final member of the Itanium family. These chips are likely to only end up in HP-based Integrity i6 high-uptime servers running HP-UX, and start at $14500. Hewlett Packard Enterprise has stated previously that it will keep support for Itanium-based products until 2025, with the latest OS update (HP-UX 11i v3 2017) coming in June.

As for the processors themselves, four 9700 processors form the stack, with quad-core and eight-core parts all with hyperthreading, differing in frequency, power, and L3 cache.

Intel Itanium (Kittson) CPUs
L3 TDP Cost*
Itanium 9760 8/16 2.66 GHz 32 MB 170 W $4650
Itanium 9750 4/8 2.53 GHz 32MB 170W $3750
Itanium 9740 8/16 2.13 GHz 24 MB 170 W $2650
Itanium 9720 4/8 1.73 GHz 20 MB 130 W $1350

*Cost is listed for the equivalent Poulson CPUs.

The base silicon comes in at 3.1 billion transistors, and are made on Intel’s 32nm process. Memory is supported up to DDR3-1067, with two memory controllers but support for scalable memory buffers is present. This is similar to the 9500 series, code-named Paulson. These chips are designed to be purely a drop into previous systems. Intel isn’t announcing an official press release around this, and unlike other ‘new architectures’, there are next to zero improvements. According to the documents, the only change is that the top two SKUs get a clock bump:

There’s probably something new under the hood, perhaps for a specific end-customer, but at this time Intel is directing anything 9700 related to equate to the 9500 series. Customers still interested in Itanium are directed to HPE resellers. 

Carousel Image from Konstantin Lanzet (Wikipedia) of Itanium 2 (Poulson)
News Source: IDG

Comments Locked


View All Comments

  • mode_13h - Thursday, May 11, 2017 - link

    GPUs serve as an example of what it takes to do in-order well. You just need workloads with enough concurrency... that's all.
  • SarahKerrigan - Thursday, May 11, 2017 - link

    GPUs aren't running anything close to workloads as generalized as IPF was.

    For servers, latency matters.
  • mode_13h - Thursday, May 11, 2017 - link

    I get that. I'm just pointing out what you have to do to your workload for in-order to make sense in throughput-optimized contexts.
  • mode_13h - Thursday, May 11, 2017 - link

    BTW, thanks for dropping your knowledge on us. It's interesting to hear the perspectives of insiders.
  • Alexvrb - Thursday, May 11, 2017 - link

    You should probably research the Itanic more before you go blaming Microsoft. They supported it as best as they could from 2001 to 2008. Sales were poor and the ecosystem was tiny. I'm surprised they supported it as long as they did.
  • SarahKerrigan - Thursday, May 11, 2017 - link

    Yep. Microsoft's IPF involvement was almost entirely driven by large MSSQL installations that wanted the extra RAM and bandwidth IME.
  • aryonoco - Thursday, May 11, 2017 - link

    There was far more Linux installations on IA-64 than there ever were Windows installations, but even RedHat killed RHEL for Itaniums long ago.

    Itanium's job was to kill off big iron Unix, and it mostly succeeded. Alpha, SGI even Sparc are all dead or in the process of dying. Only IBM's POWER seems to have survived.

    it's a funny exercise to ponder what would have happened if AMD had not created x86-64. Would Intel have finally made x86 64-bit? Or would we all be running some form of Itanium now? And would the compilers have finally figured out how to optimise for it?
  • SarahKerrigan - Thursday, May 11, 2017 - link

    Couple things.

    -SGI was looking for the exits long before IPF shipped. Look at SPEC numbers for MIPS parts starting at, like, 1998; it wasn't pretty. SPARC is currently outselling Itanium by a significant margin and both Oracle and Fujitsu have future generations roadmapped.

    -As far as I know, Intel had 64-bit programs at two different points - an internal 64-bit x86 program around 2000, and a 64-bit RISC design in the early 1990s (IAX) which was killed when Intel bought into HP's advanced processor effort (which became IPF)

    -"Compilers optimizing for it" is an easy trope to trot out for IPF's failures, but it had fundamental issues that weren't just compiler trouble. In-order processors have a godawful time handling memory latency, especially when your access patterns aren't predictable. IBM approached this problem with runahead; the HP/Intel solution was just "schedule your loads earlier, dammit (and here's Advanced Loads and Speculative Loads to help out - at least on trivial code streams)" and it didn't work well at all. There are good reasons in-order microarchitecture is dead in high-end processors.
  • mode_13h - Thursday, May 11, 2017 - link

    I agree that the writing was already on the wall, for most of the big iron. BTW, along with SPARC and POWER, PA-RISC seems to be one of the hold-outs. SPARC and now POWER are interesting cases, because they're open standards. I read some compelling speculation that Intel's legal department did as much to sink the Itanic as anything else did, by creating so many legal hurdles for would-be clones that anyone using it would be submitting to single-vendor lock-in.

    As for in-order, it's not even found in the performance-optimized ARM cores or even Atom (since Silvermont). The only times it makes sense is in power-optimized designs and when you have boatloads of concurrency (i.e. GPUs). In fact, HD Graphics is probably the only current in-order Intel architecture.
  • SarahKerrigan - Thursday, May 11, 2017 - link

    PA-RISC is gone, folded into Itanium (which was, after all, originally designed as the long-term evolution of PA, starting about thirty years ago). PA-8900 (2004ish? it's been a while) was the end of the line.

Log in

Don't have an account? Sign up now