Microsoft: it’s the end of the line for Itanium support

With x64 growing in scalability and reliability, Microsoft has decided to …

Windows Server 2008 R2, SQL Server 2008 R2, and Visual Studio 2010 will represent the last versions to support Intel's Itanium architecture, Microsoft has announced on its Windows Server blog. Mainstream support for Windows Server 2008 R2 will end on July 9, 2013, with extended support ending five years later.

With most Itanium systems being used with HP-UX, this is not surprising. Microsoft already dropped Itanium support for desktop Windows with the release of Windows Vista, and with Windows only making up an estimated 5 percent of Itanium installations, the death of the server product seemed likely to follow. Microsoft is not the only company to drop the platform, either; Red Hat announced late last year that it would be ending Itanium support, as the level of usage did not justify the continued development effort.

Itanium was never a mass-market product, and the increased capabilities of x64 hardware have diminished its appeal in most scenarios. While Itanium once had reliability and scalability capabilities not found in x64 processors, this is no longer the case; Intel's latest processor offerings, the Xeon 7500 series, matches the Itanium platform for both scalability and reliability. This means that large mission-critical single-image systems with hundreds of cores have little need for Itanium; x64 will suffice.

Given the lack of widespread use of Windows on Itanium, the decision is unlikely to make much difference to Itanium sales; it is, however, sure to worsen the perception of IA64 as a dying platform. Coupled with Intel's consistent inability to release new versions on time and failure to ramp clock-speeds aggressively, IA64's future certainly looks pretty bleak.

It was. What's happened since is that the cost of implementing x86 vs a risc architecture has fallen from ~1/3rd of the die in the P6 era to only a fraction of a percent of a desktop chip now. At the same time AMD successfully extended 64bit support to the x86 architecture and Intel followed suite. At this point the only thing the itanic still has going for it is huge cache sizes (IIRC 20-30MB on the current model). It'll probably end up being cheaper for intel to eventually just start making a monster-cache xeon.

The x86 overhead might still be semi-relevant for the atom in it's failing assault on the mobile market but even there it should only be a few percent and the fact that intel hasn't publicly announced a low power version of the current generation (the old Z series atoms went as low as .5W TDP for the cpu) is probably a bigger concern in that it's power consumption levels are presumably still not quite as low as an ARM chips.

Given the lack of widespread use of Windows on Itanium, the decision is unlikely to make much difference to Itanium sales; it is, however, sure to worsen the perception of IA64 as a dying platform. Coupled with Intel's consistent inability to release new versions on time and failure to ramp clock-speeds aggressively, IA64's future certainly looks pretty bleak.

Reading the reporting on Itanium, I have long felt it represents represents a mix of Intel's:

A) Desires to move everyone away from the competitive x86 platform onto a proprietary Intel platform.B) Hubris in its ability to follow an unproven path to success (They bet that they could put most of the path prediction into software compilers, instead of run time hardware).C) Stubborn insistence that enough money and resources can overcome intractable design problems.D) Trying to live up to promises made to their customers (HP, etc.) who gave up competing technology to switch to Itanium.

I am sure there are many good things for Intel that came out of all the Itanium projects. This is another sign that the Itanium becoming the market success they wanted, and especially their long since abandoned desire to use it to supplant the x86, will never occur.

Edit: I also feel the list is strongly weighted in the order of A to D, and that their desire to move everyone to a proprietary, non-competitive environment (A) was by far the primary reason for Itanium. Intel has long shown through its anti-competitive practices that it really prefers to never need to compete with anyone for anything.

I thought Itanium was supposed to be this super-awesome wave of the future when it was reported on Ars in the past. So it was just a flash in the pan, or too complicated for its own good, or ...? Inquiring minds want to know.

Itanium effectively died when AMD went with AMD64 (x86-64) - the Itanic was meant to replace x86 (originally). Chip delays as well as the fact that compilers for IA64 were difficult to write and implement didn't help, not to mention the fact that the Itanium architecture isn't really suited for a lot of work loads (when compared to cost/performance ratios with x86 and x86-64 systems, which it was meant to supplant). On paper in 1994 the EPIC variant that was Itanium was perhaps a good idea, but in implementation compared to IBM POWER or x86-64 by 2001 when it became a reality was another story.

IIRC, Itanium wasn't a RISC chip, it was a VLIW chip. The idea was to move the scheduling intelligence out to the compiler. Doubt it was well supported by gcc, or, really, anything other than an Intel-made compiler, and with JIT languages, probably this would be even more difficult to support. I suspect, also, that it was more difficult to scale, and keep efficient, from a multi-core point of view.

IIRC, Itanium wasn't a RISC chip, it was a VLIW chip. The idea was to move the scheduling intelligence out to the compiler. Doubt it was well supported by gcc, or, really, anything other than an Intel-made compiler, and with JIT languages, probably this would be even more difficult to support. I suspect, also, that it was more difficult to scale, and keep efficient, from a multi-core point of view.

The Itanium scaled far beyond what x86 can currently achieve.

Just look at the massively parallel systems like the Superdome and Altix.

The good news (if there was any) is that most of the Alpha team went to AMD.

That was probably the best thing that could have happened. The Athlon was basically an Alpha modified to natively run x86 code. Without it AMD would have died 10 years ago and we would all be stuck with an Intel monopoly. AMD's new CEO is one of the Alpha designers.

I strongly recommend watching Bob Colwell's talk "Things CPU Architects Need To Think About" where he discusses many CPU related things including the go ahead on the Itanium being based on a few hand coded instructions from an inner loop on one Spec benchmark. Bob was lead on the Pentium Pro up to Pentium 4 and the talk is educational as well as funny. The inside story on the Pentium floating point bug is great.

I'm surprised Intel even bothers to still manufacture the Itanium--I thought new versions of the architecture were cancelled a while ago and it was only being supported as a 'legacy' product for businesses with large investments in Itanium servers.

The amazing thing about Intel, however, is that they are so large, so integral and so dominant in the market that they have easily afforded the >$10Billion research and development loss inherent to the Itanium flop.

x86 beats a better designed ISA once again... It's kind of a shame. If you look at the itanium ISA, they have some really cool things, like a stack that uses registers instead of memory, thus vastly reducing the number of memory accesses.

That said, all of my computing devices run x86 or ARM... being cheap, ubiquitous, and backwards compatible beats other architectural considerations.

I'm surprised Intel even bothers to still manufacture the Itanium--I thought new versions of the architecture were cancelled a while ago and it was only being supported as a 'legacy' product for businesses with large investments in Itanium servers.

The amazing thing about Intel, however, is that they are so large, so integral and so dominant in the market that they have easily afforded the >$10Billion research and development loss inherent to the Itanium flop.

No, I'm pretty sure they have some long-term commitments to HP to maintain and refresh the Itanium for a while. Eventually it will be cheaper for them to integrates some of the Itanium features into the Xeon and have HPUX and Tandem switch to that then it will be to continue to refresh Itanium.

I had no idea you could get an Itanium version of Windows XP. The Itanium had some nice features; you could run it big-endian, and it had a population count instruction. But it has to do division in software, and its ISA was tied to a very specific superscalar implementation.

Not really. ia64 had a lot of neat features, but it also had some serious drawbacks, and that is a big part of why it failed. If Intel wanted to kill x86 in favor of a better ISA, they had two options. They could adopt or design a conservative, state-of-the-art RISC-like CPU. They would probably end up with something vaguely like PPC. I think they would have had a high probability of success here. It would have been easier to make a high performance x86 emulation layer on top of a more conventional CPU, so they could continue to keep the binary compatibility advantage. They would not be as strongly differentiated in architecture from their competition, but in retrospect their fab tech and their design skills is was what would continue to drive their performance and performance/$ advantages. The other option, and the one they choose, is to gable that they could make a risky and unproven architecture work and get a performance edge that way.

I don't really know what it looked like from the trenches, and how easy it should have been to see that ia64 was a doomed path. However, I can say that in the computing industry the radical unproven tech looses to the conservative incremental improvement way more often that the other way around.

I guess it is predictable that the tech press would present this as a failure of IPF.

The fact is that HP-UX with Oracle 11g gets you twice the performance on a highIPF system as Windows 2008 with SQL 2008. Then there are the reliability studiesthat show downtime avoidance is far better with just about any Unix than Windows.MS can't compete on big iron and is retreating back to standard high volume x86where it is comfortable.

IA64 isn't dead, and I'm pretty sure it's not even really dying. There was a time when Intel wanted IA64 to be the mainstream 64 bit computing platform, but that is long gone. IA64 is now the replacement for Alpha to run VMS, PA-RISC to run HP-UX and MIPS to run Tandem. It's effectively HP's microarchitecture for high-end proprietary systems, and I doubt that's going to change.

It helps that HP has designed some pretty compelling systems around IA64.

It's worth pointing out as well that the Itanium edition of Windows Server is a shadow of its x86 and x86_64 counterparts. No really, check out the "Server Role" comparison between the Itanium edition (the only edition for the Itanium) and the other editions (all x64 for 2008 R2, x86 and x86_64 for 2008):http://www.microsoft.com/windowsserver2 ... roles.aspx

So, basically, you can run a Web Server and an Application Server (a term for an amalgamation of .Net Framework enterprise stuff). That's it. No Domain Services, Certificate Authorities, DHCP, DNS, Terminal Services, and so on. My point being, Itanium has been very much a second (or third class) citizen as far as feature set since at least Server 2008. Worse yet, Itanium is an expensive hardware platform, and the pricing of the Itanium edition is the same as Datacenter edition, despite having a fraction of the featureset:http://www.microsoft.com/windowsserver2 ... icing.aspx

I can't possibly imagine how Itanium in a Windows environment is even remotely good value, unless you managed to get locked into it during the early hype, and now can't easily move away to x64 or Unix.

it represents represents a mix of Intel's:A) Desires to move everyone away from the competitive x86 platform onto a proprietary Intel platform.B) Hubris in its ability to follow an unproven path to success (They bet that they could put most of the path prediction into software compilers, instead of run time hardware).

with Microsoft as an enabler. M$ was very quick to sign onto Intel's plans, I suspect with the same motives.

I guess it is predictable that the tech press would present this as a failure of IPF.

The fact is that HP-UX with Oracle 11g gets you twice the performance on a highIPF system as Windows 2008 with SQL 2008. Then there are the reliability studiesthat show downtime avoidance is far better with just about any Unix than Windows.MS can't compete on big iron and is retreating back to standard high volume x86where it is comfortable.

But what *else* is it good for? Unless the app absolutely needs the best FP perf, the Itanium platform is just too expensive from a cost/performance ratio. The EPIC design itself was good - back in the late 80s, when it was envisaged. However, for most workloads, it's just not performant enough or easy enough to develop for to justify the cost compared to alternatives (including using servers running Intel's own Xeon).

it represents represents a mix of Intel's:A) Desires to move everyone away from the competitive x86 platform onto a proprietary Intel platform.B) Hubris in its ability to follow an unproven path to success (They bet that they could put most of the path prediction into software compilers, instead of run time hardware).

with Microsoft as an enabler. M$ was very quick to sign onto Intel's plans, I suspect with the same motives.

I agree.

I suspect at the time Microsoft thought Intel might be able to pull off a replacement for the x86, and was afraid to be left out, if Intel's plan for Itanium worked out. Microsoft has shown a desire to be the "One OS to rule them all", although it has had less success as they tried to migrate away from the desktop and x86 based hardware. Microsoft had originally designed Window NT with a hardware extraction layer to allow it to support other processors, such as MIPS and Alpha, so porting for the Itanium was not that much of stretch for them. And the x86 servers have taken a lot of market share away from the other CPU architectures. In any case, Microsoft doesn't see Itanium as viable market for them anymore.

And, Hewlett-Packard was (and remains) another enabler. They originally partnered with Intel on the Itanium design. So some of the hubris lay at their feet too. They later decided to give up their efforts and let Intel take over the entire project, but still dumped their own PA-RISC, and the inherited ALPHA architecture to support it. If I understand correctly, HP is the primary OEM selling Itanium systems today. They will continue supporting their version of UNIX for Itanium systems as long as people will buy them.

And, Hewlett-Packard was (and remains) another enabler. They originally partnered with Intel on the Itanium design. So some of the hubris lay at their feet too.

Considering this was HP's design (it was a VLW design from HP's EPIC design/research from the late 80s and early 90s), and Intel was their partner (not the other way around), it's not surprising that HP is the largest reseller of Itanic systems.

I thought Itanium was supposed to be this super-awesome wave of the future when it was reported on Ars in the past. So it was just a flash in the pan, or too complicated for its own good, or ...?

Inquiring minds want to know.

It was a ten-year long flash in the pan, but it should have been a lot shorter.

From what I remember, it was supposed to be the thing that replaced x86 when we all went 64-bit, until AMD came along and created a 64-bit x86 standard which made it un-necessary (un-necessary being different from being obsolete).

As computing power went up (in particular, when AMD came out with AMD64 they were on a roll, toweling up Intels CPUs across the board) the advantages of running a newer architecture got smaller and smaller, while the advantages of running x86 compatible processors became larger and larger.

Virtualisation became quite big as well in the meantime, and it's much (MUCH) easier to virtualise an x86 OS on top of an x86 processor. It's effectively impossible to do that with a non-x86 processor (I mean run a virtualised x86 OS on a non-x86 CPU, not that virtualisation is only possible on an x86).

So anyway, death by a thousand knives, or one big knife labelled "Red-headed Stepchild of CPU's everywhere".

Someone else might be able to give a better explanation, but I reckon that's about it.