Linux 6.7 Set To Drop Support For Itanium IA-64

[Dawn]

https://ark.intel.com/content/www/us/en/ark/products/codename/32203/products-formerly-kittson.html

dlq84 last produced Itanium CPU were made in 2017 that I can find. I could say some of the last Itanium buyers might be having a very bad case of buyers remorse.

Also note they are 2017 chips but they are also only 32nm

https://ark.intel.com/content/www/us/en/ark/products/97486/intel-pentium-processor-g4600t-3m-cache-3-00-ghz.html

x86 processor from intel of 2017 is 14nm.

The "Itanium 9700" was just a +133MHz refresh of the 2012 Itanium 9500 "Poulson" series, with no new die, so Intel could say they delivered their roadmap. Actual work on new Itanium gens was canceled in January 2013.

[Dawn]

The last remaining Itanium user is shaking right now.

There are still quite a few Itanium users - just not (mostly) running Linux. UX end of support is 31 Dec 2025 and there are still thousands of users on it. I think the Nonstop base has mostly migrated at this point. There are also a decent chunk of OpenVMS users - I'd guess at least a thousand - on Itanium, and they don't have a clear migration path off it until the x86 VMS port gets stronger ISV support.

[Dawn]

Intel lost badly on the Itanium. They could not just reduce the node size and hope for the best. Performance was so abysmal, especially in x86 compatibility mode that they had to invest massive engineering resources in rebuilding the cpu several times.

I am not certain, but I think HP did all right on their side as they pretty much exclusively used Itanium in their non-stop server line where it worked out quite well, even at its lower performance threshold.

I think Oracle also got burned in this adventure, weren't they required by contract to keep their database running on Itanium long past its profitability?

In the end, I personally liked a bunch of the design decisions in Itanium... but I never had to program for the beast, and am given to understand it was only rivalled by the Cell processor in its abuse of the programmer.

They really should have just made Itanium their first "Compute Card" and kept it as an add on to an x86 CPU. There was groups doing this with the Cell CPU at one point (https://techreport.com/news/mercury-...-a-pci-e-card/).

For a number of years, performance was just fine. Core for core, Madison through Montvale outperformed its x86 contemporaries while offering better scalability (albeit at the cost of being somewhat brittle and more expensive.) There's a reason it kept being used in supercomputers like Columbia even when x86 was cheaper.

Eventually the weight of cumulative delays and missteps added up, and x86 got credible for mission-critical uses when Nehalem-EX came out. After that point, there was no longer any reason to run Windows or Linux workloads on it and it became purely a platform for Itanium-specific operating systems (UX, VMS, Nonstop, SourceT, GCOS8.)

[zexelon]

For a number of years, performance was just fine. Core for core, Madison through Montvale outperformed its x86 contemporaries while offering better scalability (albeit at the cost of being somewhat brittle and more expensive.) There's a reason it kept being used in supercomputers like Columbia even when x86 was cheaper.

Eventually the weight of cumulative delays and missteps added up, and x86 got credible for mission-critical uses when Nehalem-EX came out. After that point, there was no longer any reason to run Windows or Linux workloads on it and it became purely a platform for Itanium-specific operating systems (UX, VMS, Nonstop, SourceT, GCOS8.)

Yes you are correct, its performance exceeded x86 substantially... in very specific, very parallel use cases and only when fully programmed in its native IA64 instruction set. If you were trying to run in x86 compatibility mode, early editions were utterly abysmal and later editions were merely passable. It was also far more difficult to build optimized compilers for this ISA than originally thought.

[CommunityMember]

Itanium was too far ahead of its time, in that the compilers, of its day, could not properly schedule the EPIC (a VLIW variant) pipeline, leaving a lot of potential performance on the table. And Intel's choice to not cannibalize its existing cash cow (x86) production by using the more advanced lithography was another factor that contributed to Itanium's minuscule market share. AMD (with its 64-bit extension(s) for x86) put the nail in coffin, although Itanium continued as the living dead for quite some time. Itanium did have a place in certain high performance computing deployments where there was value in throwing programmers at optimizing their code for the architecture.

[Dawn]

Itanium was too far ahead of its time, in that the compilers, of its day, could not properly schedule the EPIC (a VLIW variant) pipeline, leaving a lot of potential performance on the table. And Intel's choice to not cannibalize its existing cash cow (x86) production by using the more advanced lithography was another factor that contributed to Itanium's minuscule market share. AMD (with its 64-bit extension(s) for x86) put the nail in coffin, although Itanium continued as the living dead for quite some time. Itanium did have a place in certain high performance computing deployments where there was value in throwing programmers at optimizing their code for the architecture.

Itanium systems outsold Opteron systems for many years. I don't get this "Opteron killed Itanium" narrative and never have.

https://images.anandtech.com/doci/4285/Risc_loss.png for instance.

[Dawn]

Yes you are correct, its performance exceeded x86 substantially... in very specific, very parallel use cases and only when fully programmed in its native IA64 instruction set. If you were trying to run in x86 compatibility mode, early editions were utterly abysmal and later editions were merely passable. It was also far more difficult to build optimized compilers for this ISA than originally thought.

"Processor running emulator has substantial performance penalty! Film at 11!"

Who gives a shit? That's relevant to the NT folks and almost nobody else. Shockingly, Itanium's major competitors - Power, SPARC, Z - would also have poor performance emulating x86.

[zexelon]

"Processor running emulator has substantial performance penalty! Film at 11!"

Who gives a shit? That's relevant to the NT folks and almost nobody else. Shockingly, Itanium's major competitors - Power, SPARC, Z - would also have poor performance emulating x86.

100% true... but the entire market cared... very deeply. Itanium was the first major 64bit ISA from Intel and was billed as the "transition from 32bit to 64bit". Unlike your other examples Itanium does include x86 hardware instructions in it, and in all its incarnations clamed full x86 compatibility. Literally NONE of your other examples do that. Its just that in Itanium the completely butchered the x86 implementation in some half baked (probably marketing driven, but thats pure hearsay) attempt to drive people to the IA64 implementation.

Also Opteron completely crushed Itanium. Itanium was first to market, that was its only win in the sales side. It was then promptly relegated to niche markets like the HP nonstop servers.

Aggressiveness is a poor substitute for reason.

[mdedetrich]

Yes you are correct, its performance exceeded x86 substantially... in very specific, very parallel use cases and only when fully programmed in its native IA64 instruction set. If you were trying to run in x86 compatibility mode, early editions were utterly abysmal and later editions were merely passable. It was also far more difficult to build optimized compilers for this ISA than originally thought.

Right but any compatibility mode is going to be substantially lower than using the native instruction set so not sure what point you are making here. Similar to Rosetta for Mac systems, the whole point of these compatibility modes is to provide a bridge for the native instruction set and not something to be used if you want top performance.

So to me saying that the x86 compatibility mode in IA64 was slower than x86 is kinda like, "well duh".

[Dawn]

100% true... but the entire market cared... very deeply. Itanium was the first major 64bit ISA from Intel and was billed as the "transition from 32bit to 64bit". Unlike your other examples Itanium does include x86 hardware instructions in it, and in all its incarnations clamed full x86 compatibility. Literally NONE of your other examples do that. Its just that in Itanium the completely butchered the x86 implementation in some half baked (probably marketing driven, but thats pure hearsay) attempt to drive people to the IA64 implementation.

Also Opteron completely crushed Itanium. Itanium was first to market, that was its only win in the sales side. It was then promptly relegated to niche markets like the HP nonstop servers.

Aggressiveness is a poor substitute for reason.

HP designed Itanium as a long-term evolution of PA. For its userbase, x86 compatibility was largely irrelevant, because HP-UX never ran on x86 to begin with. The only use of x86 compatibility I ever saw was running x86 utility software on large Windows Server systems, and for that, the fact it had a 50%+ penalty didn't matter at all because those were not CPU-bound applications (I'm talking about stuff like PuTTY here.)

Also, "crushed Itanium" at what? Look at sales numbers for 2007-2009, when Itanium and Opteron had both been around for years. It's one-sided, and not in favor of Opteron. If you say "performance", take a look at SPEC and TPC numbers for the same period.