Linux Deleted a $10 Billion Intel Chip in One Commit. Itanium Took 23 Years to Die

An entire CPU architecture got deleted in a single commit. That is the short version of how Itanium ended. In Linux 6.7, which shipped in January 2024, the kernel removed every line of support for Intel’s IA-64, about 65,000 lines, because not one person was left who could test it or answer for it. The chip had cost Intel and HP something like $10 billion to build, it was once projected to own the server market, and it exited the most used operating system in the world as a routine cleanup.

I want to walk through how that happens, because the gap between the ambition and the ending is enormous, and the reasons are specific.

The idea was genuinely clever

In the early 1990s HP looked at its own PA-RISC chips and at x86 and decided neither would keep scaling. So in 1994 it teamed up with Intel to build something new. The idea was a real bet on a different way to run code.

A normal processor works out, while it runs, which instructions can happen at the same time. That is out of order execution, and the scheduling hardware that does it costs transistors and power. Itanium’s pitch was to skip all that. Let the compiler decide ahead of time which instructions can run in parallel, pack them into bundles, and let the chip just execute what it was handed. A simpler chip paired with a smarter compiler. They called the approach EPIC, explicitly parallel instruction computing.

On paper it was elegant. Move the hard thinking from the silicon, where it is expensive, to the compiler, where you only pay for it once. The whole industry believed it. HP and Intel announced Itanium in 1997 and promised chips in 1999. The analyst firm IDC projected around $38 billion in Itanium sales by 2001. Vendors wound down their own chip lines to get ready for it. Compaq dropped its Alpha line. Only one major player refused to climb aboard, AMD, which turned out to matter later.

The forecast against the reality. IDC projected $38 billion in Itanium sales by 2001. The real number was a rounding error next to it. Source: IDC 1997 forecast, contemporary reporting

The compiler could not do the one thing it had to do

The first chip, codenamed Merced, shipped in 2001, 2 years late and slow. The press already had a nickname ready. The Register had been calling it the Itanic. A slow launch alone does not kill a chip with this much money behind it. The design itself is where the trouble was.

The whole scheme depended on the compiler knowing, at compile time, how long every memory access would take, so it could pack the bundles efficiently. That timing depends on what is sitting in the cache at that exact moment, which the chip knows while it runs and the compiler cannot know in advance. Asked to schedule something it could not predict, the compiler did the safe thing. It filled the bundles with empty instructions that do nothing, called no ops, so it would not break anything. A large part of the chip’s width ended up executing air. The elegant idea needed a compiler that could see the future, and nobody knew how to write one.

The second problem was compatibility. Itanium could run existing x86 software, but through emulation, at a fraction of native speed. So the pitch to a customer was to buy an expensive new chip that ran the programs they already owned worse than the cheap chip they already had. That is a hard sell, and it left a door wide open.

AMD walked through the door Intel left open

In 2003 AMD did the obvious thing Intel had refused to do. It stretched x86 to 64 bits and kept everything that already ran at full speed. It called the result AMD64. No clean break, no throwing away your software, just more address space on top of the instruction set the whole world already used. Linux supported it within months.

Then the decisive move. Microsoft agreed to build Windows for AMD64 and told Intel it would not ship a second, separate 64-bit version of Windows for a different instruction set. Intel was cornered. It could keep fighting its own customers with Itanium, or adopt its rival’s design. In 2004 it did the second thing, copying AMD’s extension and selling it in its own chips as EM64T, later renamed Intel 64.

That decision is why, if you open the system details on almost any Intel machine today, the architecture is listed as x86–64 or AMD64. Intel’s own processors carry a competitor’s name on the instruction set, because the chip Intel built to kill x86 instead made AMD’s version of x86 the permanent standard.

The timeline, from the 1994 partnership to the 2024 kernel deletion. The chip outlived its own relevance by about 20 years. Source: Intel, HP, kernel history

The deeper reason the bet was doomed

The compiler idea could not win for a structural reason, not because nobody tried hard enough. The whole premise was that a smart compiler could schedule instructions better than the chip could at runtime. That works only when the compiler can predict how the program will behave, and the single biggest variable in modern performance is memory latency, how long it takes to fetch data. A value already in the fast cache comes back in a few cycles. A value that has to come from main memory can take hundreds. Whether it is in the cache depends on everything the program did just before, which changes run to run and input to input.

A compiler sees the program once, at build time, with no idea what will be in the cache when a given instruction runs. The chip sees the real state every cycle. So the very thing Itanium moved into the compiler, scheduling, is the thing that most needs live information the compiler does not have. Out of order execution on a normal chip is not wasteful overhead to be optimized away. It is the chip reacting to reality as it unfolds, which a static schedule cannot do. That is the part Itanium’s elegant diagram left out, and no amount of compiler research closed the gap.

Linux carried it for 23 years

Here is the part I did not expect. Linux ran on Itanium before the chip even shipped, because the industry paid to make it happen. In 1999 Intel, HP, and a group of Linux companies including Cygnus, VA Linux, SGI, Red Hat, and SUSE formed the Trillian Project to port Linux to IA-64 ahead of the hardware, and they released the source in early 2000, a year before Merced reached customers. Debian, Red Hat, and SUSE all shipped it. For a while it was a real, supported platform with real money behind it.

Then the slow retreat. Red Hat announced in December 2009 that it would drop Itanium in RHEL 6, which shipped in 2010, saying the number of Itanium servers sold was too low to justify the support. Debian carried it one release longer, keeping it in Debian 7 and dropping it from Debian 8 Jessie in 2015. Intel took its last Itanium orders by January 2020 and shipped the final chips, the Itanium 9700 Kittson, by July 2021. HP kept supporting its own Unix on the hardware through the end of 2025. By 2023, though, nobody on the kernel mailing list was answering for IA-64 anymore. The architecture was marked Orphaned in the kernel’s own MAINTAINERS file, which is the formal way of saying no company and no volunteer will speak for this.

In September 2023 the engineer Ard Biesheuvel proposed removing it, with a patch note that said simply that the Itanium architecture is obsolete. Linus Torvalds accepted it, and the removal shipped in Linux 6.7 in January 2024. About 65,000 lines, gone.

Why delete working code at all

Plenty of people assume old code gets deleted because it is old. That is not the rule, and Linux proves it constantly. The kernel only recently retired support for the Intel 486, a chip from 1989. It carried a graphics driver dating back to 1982 for years. Age alone does not get code removed.

The actual rule is about testing. When nobody can run the code, every change to the kernel risks breaking it silently, and nobody will notice until it is too late. Every supported architecture is a tax on everyone else. Anyone who changes a core kernel interface has to update every architecture it touches, including the ones nobody owns or tests. The asymmetry tells the whole story. Itanium support was added because HP paid for it. It was removed because nothing showed up, nobody answered the mail, and the cost of pretending it still worked outgrew any benefit.

Age does not get code deleted. A lack of anyone to test and answer for it does. Source: kernel maintainer discussion, 2023

Torvalds saw it early, and the history proved him right

Torvalds had been skeptical of Itanium’s whole premise for a long time. Back in February 2003, in a kernel mailing list debate, he put it bluntly. He said Intel had thrown out all the good parts of the x86 because people thought those parts were ugly, and that those were the parts that actually make x86 perform. He added that the Itanium 2 did not hold a candle to a Pentium 4 on any real world benchmark, and that IA-64 simply could not do the things a Pentium 4 did every single day. Information Age ran his view under the headline that Itanium is horrible, says Torvalds. The complaint underneath was about the arrogance of the opening move, asking everyone to throw away the software they already ran in exchange for a promise that the hardware never delivered.

That distrust has aged well, and it generalizes. Any time a company tells you the future requires a brand new architecture and a clean break from everything you own, the burden is on them to make the switch painless, and they almost never do. The lesson of Itanium is that compatibility is not a limitation to escape. It is most of the value.

The idea did not actually die

The strange epilogue is that Itanium’s core idea outlived the chip. The notion of letting software decide the schedule ahead of time, instead of the hardware working it out live, came back in places where it fits. Parts of the GPU and AI accelerator world lean on exactly that approach, because their data patterns are predictable enough that you really can plan ahead. The idea works where the workload is predictable. It fell apart on general purpose CPUs running unpredictable code, which is the one job Itanium was built for.

The other half of the Itanium story came back too, and got it right. Moving to a brand new architecture with emulation for old software is exactly what Apple did with its move to Arm, and what Qualcomm is doing in Windows laptops. The difference is that their emulation is fast and native software arrived quickly, which is the thing Itanium never managed. RISC-V takes the opposite lesson in a different way, with an open instruction set that no single company can decide to abandon, which is its own answer to the problem of one owner walking away.

Intel spent roughly a decade and around $10 billion trying to retire x86. What it left behind is a competitor’s name on its own chips and about 65,000 lines of deleted kernel code. Linux carried the thing for 23 years, longer than Intel itself kept wanting it, and let it go the day nobody answered the mail.