Slashdot Mirror
Intel's Itanium CPUs, Once a Play For 64-bit Servers And Desktops, Are Dead (arstechnica.com)
Reader WheezyJoe writes: Four new 9700-series Itanium CPUs will be the last and final Itaniums Intel will ship. For those who might have forgotten, Itanium and its IA-64 architecture was intended to be Intel's successor to 32-bit i386 architecture back in the early 2000's. Developed in conjunction with HP, IA-64 used a new architecture developed at HP that, while capable as a server platform, was not backward-compatible with i386 and required emulation to run i386-compiled software. With the release of AMD's Opteron in 2003 featuring their alternative, fully backward-compatible X86-64 architecture, interest in Itanium fell, and Intel eventually adopted AMD's technology for its own chips and X86-64 is now dominant today. In spite of this, Itanium continued to be made and sold for the server market, supported in part by an agreement with HP. With that deal expiring this year, these new Itaniums will be Intel's last.
I guess I just sort of assumed that IA-64 was dead a long time ago, and figured Intel's gaming the benchmarks was essentially retribution against AMD for the success of amd64 architecture.
Does anyone remember the reasoning for dropping native support for i386 when these processors debuted? There have always been growing-pains when a manufacturer drops or severely impacts support for their install-base, but sometimes it's beneficial or necessary if an existing architecture is a dead-end.
Do not look into laser with remaining eye.
It never was a very good architecture, but there was a VMS port to it.
If I remember correctly, it was revealed a few years back that HP was paying Intel to continue developing Itanium simply because it had bet on the processor for its Integrity servers, which run HP-UX, NonStop OS and used to be the only place to run OpenVMS. Obviously these are legacy operating systems, but where they're used they're highly entrenched and can't be written off with an "oh, just migrate to x86 Linux and Java" kind of mindset. OpenVMS is actually living on; HP sold the development rights to a new company who is porting it to x86 -- interesting to me because that was the first ever OS I supported in any professional capacity. But, it looks like HP-UX is probably going to get killed as slowly as an OS like that can.
There was also a tiny window where Itanium had some life, around the early 2000s before x86-64 became a thing. If you had an application that required large (for that time) amounts of memory, it was basically your only choice if you didn't want to go AIX, Solaris or similar. I worked on such a system around that time (mainframe migration) and the Itaniums were pretty quirky compared to x86 servers. UEFI is one of the things that lives on from that era and actually made it over to the mainstream x86 platform.
The good ol' days, when Intel just announcing the Itanium caused all the other proprietary Unix vendors' stock to crash. Everyone was sure that within one generation, all the SPARC & POWER chips would shrivel up and die. HP rolled over immediately and gave up their line of PA-RISC procs to use Itanium. But Intel crippled their Xeons in fear that the Xeons would eat into their Itanium line, and then AMD walked in and gave people what they really wanted with their Opterons. There were a few years when things were really rocky for Intel, and it was very entertaining to watch, especially since I worked for them at the time :)
Looking for a computer support specialist for your small business? Check out
From the start it was 2 generations behind the Pentium 3/4 as far as process technology went. Plus the performance loss of the memory translator hub chips because it was designed assuming RAMBUS had won (I forget if this was both the very early limited production run SDRAM systems, or strictly the DDR1+ systems.) As such the early silicon was slow, hot, had degraded memory performance, and was saddled with a single video device and 1 or 2 PCI busses. Not an auspicious start. By the time Intel had the sense to think 'Maybe we should support both Xeon and Itanium with the same chipsets' and PCIe was popular enough to allow plenty of bandwdith for special purpose devices to help take advantage of the CPUs, it was already too late.
I will miss it. Not for Itanium itself, but rather for the much better designed alpha, pa-risc, and mips chips it killed (mostly due to even its anemic process technology being multiple steps ahead of DEC, HP, and whoever SGI was contracting with.), as well as its companion in the waning years of 'big unix' alongside SPARC and PowerPC, only the latter of which is left today, at a pricepoint well beyond what any sane new developments will build off of (except for extremely expensive limited production systems for particular niches.)
Dupe from many years back. The Itanium is well dead and buried since long, the zombies were only for extra fooled customers.
I had fond memories of the AMD Athlon 64 processor when it first came out. After owning a half-dozen Socket 7 processors and just as many motherboards, this one kicked ass and I had it for a long time. I didn't upgrade to a 64-bit version of Windows until Vista came out and I built a new system, jumping from dual- to quad- to eight-core in ten years.
https://en.wikipedia.org/wiki/Athlon_64#Single-core_Athlon_64
Itanium is a direct result of the hardware people and the software people refusing to rub elbows in the same room.
Itanium's designers basically declared war against their software peers. Our beautiful machine would run fast, if only your crappy software didn't expose so many execution hazards.
Thus Intel set up a grand gauntlet for the compiler writers to finally prove their ultimate hardware manhood: by writing an Itanium compiler that didn't suck.
We all know how that went.
I've always though the made the critical error on the first step after connecting with the baseball: the bundle should have been a collection of highly dependent instructions that only wrote back to the register file once fully executed. A bundle would be dispatched to one execution unit's queue, and sit there until complete.
Because the bundle has internal dependencies, this means that each bundle would have a significant internal latency, so each execution unit queue would need a fairly deep dispatch buffer. "Waste of silicon!" cry Intel's virtuous hardware engineers. "Latency is a thing in the world!" whimper Intel's pussy-whipped compiler writers.
I also think that for compact instruction packing, that not every input argument to a bundle should have been able to name any old register out of the giant register file (256 registers, IIRC). Maybe a few global references, then plenty of 4-bit register selectors, accessed out of register file shards (the base shard could be selected by any number of mechanisms, up to and including the program location from which the instruction bundle was fetched; so maybe the code only ends up relocatable modulo 64 or modulo 256? what a horrible tragedy—plus the compiler writers already had great register colouring algorithms, so we had somewhat of a proof-of-concept in hand for the compiler complexity).
Because you're bypassing the register file for many bundle internal arguments (the result ax in the expression ax + b never hits the register file), fewer register file (and memory) reads satisfy more total instructions. I would have liked to see a bundle of about the same size able to specify up to eight simple instructions, if sufficiently chained together.
To a certain degree, this opposite-George approach kicks determinism to the curb. Well I say better sooner than later. Hey Intel engineers, look at your vaunted determinism now, dead with a bottle on skid row, after a long, loosing battle.
(The other thing Intel liked about determinism was its first five letters. Sometimes stupid ideas present a broader field for patent lock-up land-grabs. Moral of the story: greed carefully.)
It's easy to come up with hundreds of good reasons why my opposite-George approach wouldn't have panned out any better, but a smart group of engineers is paid to find clever solutions to most or all superficial obstacles. Whether any counterfactual designs might have proved viable is permanently lost to history. I'm just relating my own instinct at the time, FWIW.
Another thing: I would have endorsed a big/little design for interrupt handling (of the asynchronous type), with only a small set of agile (aka bundle-free), little cores able to handle interrupts. Then you can really afford to thin out check-point writes back to the register file (which is always a hot point to begin with). The magical, invisible forwarding mesh to support this illusion seamlessly would still be extremely complex, but that's also true on every other modern design.
From my perspective, Itanium was plenty innovative, unfortunately, it was mainly innovative in pure stubbornness and greed.
The real reason Itanium failed isn't because it was inferior but rather because they failed to proliferate support for it in compilers while maintaining a higher price point. If they ensure before it's release that it were well supported by all the major compilers (instead of exclusively with Intel compilers upon release) and had a similar price to x86 chips then they could have had a real chance. Instead, they relied on their market position and expected people would catch up to them in time.
This conquer-by-market-share approach might of worked if AMD hadn't come out with AMD64 extensions we now call x86_64 that was significantly simpler (thus easier to adapt existing compilers) and less expensive than Itanium.
The poor software support and high architectural complexity mirrors the exact conditions that lead the original Sony Playstation to dominate the Sega Saturn several years earlier.
Anons need not reply. Questions end with a question mark.
The original Itanium1 had i386 compatibility.
Worked at a telecom at the time who were big HP customers so we were given a Itanium1 box as a demo.
We tried on it:
- A beta version of HP-UX (11.16) who could not run any PA-RISC code and nothing was available for it.
- Itanium RedHat
- i386 RedHat
That Itanium1 was as fast^H^H^H^Hslow as a Pentium1 in i386 Compatibility mode. Also it was slower than a PA-RISC with the same clock.
We gave it back and ordered more PA-RISC machines.
The Intaniums on the marked today are the so-called Itanium2 CPUs, totally different from Itianium1s. Itanium2 lost i386 compatibility, but gained PA-RISC one (down to CPU pinout). But they still were shitty compared to PA-RISC.
When the latest PA-RISC cpus were released, HP had anyone buying them sign an NDA that they won't release any performance benchmarks. Because they were MUCH faster than the Itaniums2 of the time.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
Intels plan was to deliver high-mhz-average-performance-pentium-4 for the broad market. Remember how the first Pentium 4 at 1.3-1.4GHz barely managed to keep up with a 1GHz Pentium 3 (or the Athlon)? The very long pipeline of Pentium 4 was meant to work well for "multimedia", and for other purposes Intel considered the CPU fast enought.
The Itanium was supposed to be superior with its 64-bit memory and good general performance, and this would make it the only viable option for servers and high performance workstations. And at a much higher price than the 32-bit P4.
Only problem was that AMD had another plan that left both Itanium and P4 in a very bad place.
Does Gentoo still work on these? Does any Linux? Does FreeBSD? HP-UX I'm sure does, but IA64 was well supported by major Linux distros until it was pretty well abandoned, long after it was a clear failure.
I've considered buying a cheapo old IA64 to screw around with, but I would want to be able to install Linux on it, if possible.
Yes, incompatibility was an insurmountable problem for IA-64, and x86-64 was what the market needed and wanted. That said, VLIW had other issues of its own that limited its success.
VLIW emerged in the mid 90's as a potential successor to RISC aimed at improving performance per chip. It had many innovative aspects and more fully leveraged advanced compiler capabilities. Unfortunately, VLIW improved only the "infinite cache" component of uniprocessor performance, and put greater load (per useful instruction executed) upon the cache/memory hierarchy. For most workloads VLIW was focused on solving the wrong problem. It was well suited though for some technical applications.
HP and Intel embraced VLIW around 1995. It looked promising at the time. It had its technology evangelists and marketing sizzle. Then multi-core chips happened (POWER4 shipped in 2001). Multi-core has proven to be the superior path forward for increasing performance per chip. Today many cores per chip is commonplace in the x86 marketplace. It's proven to be a much more effective way of using the available circuits (and power) per chip.
Perhaps VLIW plays a valuable role somewhere today but not in the commercial server or PC space.
Actually, the Itanium architecture was not very different from PA-RISC, it just allowed to issue multiple instructions to parallel execution units without the CPU trying to solve dependency issues between those execution units, leaving that task to the compiler.
I am pretty sure HP would have been better off not forfeiting their PA-RISC architecture to Intel at that time - the PA 8000 CPUs ran circles around the x86 CPU from the same time while using much less transistors.
...and finally hit the bottom. It never achieved any mass market, but did carve out a niche that wasn't sustainable.
Wonder if intel is still touchy when people call Itanium by the name Itanic instead.
Oh well. It's been Itanic for so long, I have to put in effort to remember the actual name.
Sig for hire.
Intel has a history of this. Every decade, they come out with a new ISA that is impossible for compilers to target efficiently. The iAPX432, the i860, Itanium, and now their GPUs (two-dimensional register sets sound really neat on paper, but trying to write a register allocator for them is very exciting and requires very tight coupling between instruction selection and register allocation).
I am TheRaven on Soylent News
It never was a very good architecture
EPIC was too far ahead of its time. Compiler technology was still in the research phase. The hardware implementation was harder than expected.
EPIC was a dog.
The VLIW bundles had limited encoding of instruction groups, which in practice meant the compiler was unable to use all the slots of a bundle for useful work. So, not only did code density go down, but the explicit parallelism was limited by the VLIW itself.
It's the same mistake MIPS made. They exposed the underlying hardware design (in MIPS case, the pipeline design) so that they could forgo pipeline stage interlocks for increased speed. But as clock rates grew, the number of pipeline stages needed to increase, and interlocks were required anyway, and the delay slots were similarly useless.
RISC-V has taken all this on board, and produced an orthogonal ISA, which abstracts away as much implementation detail as possible (no assumptions on pipeline design, no delay slots). I just hope RISC-V becomes a big thing in the coming years.
IBM got full of themselves and so did Intel when they implemented the Itallium. It was interesting but they priced it ridiculously and abandoned their enthusiast (aka first adapters) market.
The real reason was market monopoly, i.e. an attempt to lock out AMD. Here's the back story...
* Around 1980, IBM decided to put out an Apple ][ competitor machine, with potential sales of maybe a couple of hundred thousand during its lifetime production run
* "The IBM Way" included things like insisting on multiple sources for each component, so that no one supplier could demand higher fees on short notice, or go bankrupt and disrupt IBM's production capacity.
* Back then IBM was *BIG* in computing, and Intel was a lot smaller than today. So IBM got their way, and companies like AMD were licenced to produce clones of Intel 8088 cpus, as part of the contract that Intel got for supplying IBM.
* The IBM PC was introduced in August, 1981. Much to everybody's surprise, including IBM, it was a Y-U-U-U-U-U-G-E hit.
* The cpu used for the IBM AT was the 80286. Intel argued that it was sufficiently different from the 8088 that the second-sourcing licences didn't apply. AMD disagreed, pointing out that the 80286 could natively execute 8088 programs in hardware. I.e. it was a derivative of the 8088, and therefore subject to the licence.
* The case went to court, and AMD got their way. Part of the settlement was a more specific cross-licencing agreement between the 2 companies' IP in 8088/80286 and any future derivatives.
* Intel brought out the 80386/80486/80586 and AMD followed with their equivalant cpus. Intel was *PISSED* about
a) losing sales to AMD and
b) not being able to charge higher prices, due to competion
* So Intel decided to bring out a 64-bit cpu so radically different that it would not be covered by the 8088/80286-and-derivatives cross-licence. They wanted something/anything that competiors would not have the right to reproduce. Thus, the concept of the Itanium was born.
* The cpu was a total failure, being nicknamed "the Itanic". AMD's 64 bit cpus were backwards-compatable, and could execute 32-bit programs at full speed natively in hardware. The Itanium could only do painfully slow 32-bit emulation for existing programs.
* Intel had no choice but to follow AMD's lead and build backwards-compatable x86_64 cpus. Ironically, it was the cross-licencing agreement that AMD had won on court, which gave Intel the right to use AMD's 64-bit extensions.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user