How AMD killed the Itanium

July 15, 2005

I've been telling people versions of this story for a while, so I figure I might as well write it down for posterity (or at least entertainment).

When Intel started Itanium development work in the mid 1990s, it had a straightforward story: the x86 architecture was about to run into a performance cap, because of all the ugly warts it had inherited from its predecessors (a very limited supply of registers, a highly irregular instruction format, etc). To get the future performance that customers wanted, a modern warts-free RISC-oid architecture was needed: the IA-64.

This was no different from the stories all the other CPU vendors were telling at the same time. Unlike those CPU vendors, Intel realized something important: very few people buy new CPUs to run only new software. Even in the mid 1990s, most people were using Intel x86 CPUs to run their programs, so that was where the big CPU dollars were.

So Intel promised that there would be a magic x86 part glued on the side of the first few generations of Itaniums that would run all of your existing important programs. Because very few people are ever interested in upgrading to a computer that runs their existing programs slower, Intel needed this magic x86 part to run at least as fast as their real x86 chips.

Intel could get away with this for two reasons. First, x86 chips were relatively simple compared to the design that Intel was planning, so it should be easy to glue the core of one on the side of the new CPU. Second, Intel could make the x86 performance story come true simply by moving most of their CPU design manpower (and money) to the IA-64.

Then AMD showed up to ruin Intel's party by competing directly with them. It didn't matter that AMD didn't have faster CPUs to start with; AMD's existence meant that if Intel left them alone, AMD would surpass Intel and kill Intel's main revenue source. Intel had to crank up x86 performance to make sure that didn't happen. This probably had three effects:

  • people got diverted from IA-64 CPU design back to x86 CPU design;
  • because x86 got faster, Itanium had to get faster too;
  • the only way to make x86 faster was to make it more complicated, which made it harder to integrate a current-generation x86 into Itanium.

Naturally, the schedule for delivering a faster, more complicated Itanium slipped. Which kept making the problem worse, especially when making x86 chips go really fast started to require serious amounts of design talent. Instead of designing one high-performance CPU and doing a small amount of work on another CPU architecture, Intel was trapped in an increasingly vicious race to design two vastly different high-performance CPUs at the same time, and one of them had to be backwards compatible with the other.

It's no wonder the Itanium shipped years late, with disappointing performance and very disappointing x86 compatibility performance. (And heat issues, which didn't help at all.)

With AMD's recent x86-64 64-bit extension of the x86 architecture, Intel couldn't even claim that Itanium was your only choice if you needed 64-bit memory space and suchlike. Intel's capitulation to making its own almost 100% compatible x86 64-bit extension was inevitable, but probably the final stake in Itanium's heart. (And likely a very bitter pill for Intel to swallow.)

And that's how AMD killed the Itanium.

Written on 15 July 2005.
« The legend of Debian Linux
First Irritations with Fedora Core 4 »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jul 15 01:59:55 2005
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.