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.

Comments

It was still alive?

[TWX]

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.

Re:It was still alive?

[F.Ultra]

It was a completely different architecture so adding native i386 support would have required to add a complete i386 compute core to the chips. And the i386 architecture is a real mess so they hoped to avoid their old sins but for some reason didn't understand that their own i386 architecture already had "won". Myself I have always mourned that Motorola never could increase the frequency of the MC680x0 beyond 66Mhz and keep up with Intel because that architecture was a real beauty to program in assembler.

Re:It was still alive?

[ShanghaiBill]

Does anyone remember the reasoning for dropping native support for i386 when these processors debuted?

There was a belief by some that emulation would be "good enough" since the IA-64 would be so blazingly fast, and emulation would only be needed for a few years during the expected phase-out of x86. Meanwhile, new applications and upgrades would be issued as "dual binaries" that could run natively on either platform.

Two things went wrong with this plan:
1. The IA-64 turned out to not be as blazingly fast as Intel hoped.
2. AMD offered a good alternative at lower cost and far less hassle.

Although Intel's plan may appear unrealistic in hindsight, it actually could have worked. Apple managed a similar transition from 68k to x86 a few years later using the same strategy.

Re:It was still alive?

[amorsen]

Intel managed to kill of the Alpha and the PA-RISC with the Itanium. MIPS left the high end. SPARC and POWER looked quite endangered at one point.

All this was done while not being actually competitive at any point. You have to admire that, in an Evil Corp sort of way.

Re:It was still alive?

[F.Ultra]

It could however be connected to an external MMU that would enter the supervisor mode when the CPU entered restricted memory and later the 68030 included a proper MMU on chip. Even without a MMU the 68000 could catch segfaults which was used by Kickstart 2.4 on the Amiga to not bring down the whole machine when a single process crashed.

Re:It was still alive?

[plopez]

The other was the use of cheap laptop chips in rack servers. Why buy an expensive Itanium server when you can buy a boat load of cheap ones; allowing for more flexibility, more redundancy for fail over, and lower energy consumption?

Re:It was still alive?

[Darinbob]

I think there's a bubble effect happening with a lot of people, they can only a limited viewpoint based on seeing a monoculture for so long. Hearing these sorts of questions is sort of like heaing someone ask why Chevrolet exists when we already have Ford. They've only ever seen and used a PC perhaps and only vaguely know of other types of computers, and certainly have no background in computer architecture.

Re:It was still alive?

[ShanghaiBill]

Myself I have always mourned that Motorola never could increase the frequency of the MC680x0 beyond 66Mhz and keep up with Intel because that architecture was a real beauty to program in assembler.

The features that made the 68k so nice for assembly programming, like addressing multiple unaligned memory locations in a single instruction, are precisely what made it so difficult to speed up.

Imagine that you are a chip designer. You are implementing the silicon for "movl @a1, @a2". So you access the first byte at the address stored in a1, but you get a page fault. You trigger an interrupt, the OS swaps in the page, and then returns from the interrupt. Now, you must restart the instruction and fetch the other 3 bytes, but since the address is not aligned, they can be on a different page, so now you trigger another interrupt. The OS returns, and you can now fetch the 3 bytes. But wait a sec, what about the 1st byte? You can either go back and fetch it again, which might trigger yet another interrupt since that page may no longer be in memory, or you can have some extra "hidden" registers to hold that intermediate value (which can be one, two, or three bytes). So you deal with all that. FINALLY you have all 4 bytes. Whew. Now you need to do the SAME thing for the second operand, but that is even more complicated, because if the address straddles a page boundary you may end up with corrupted memory if one byte of the target is modified but the other bytes are not.

A single instruction can generate up to 4 pages faults (not including double faults). Now how do you deal with cache coherency on a multi-core system when a single operand can be partially read from or written to memory? Can you imagine all the silicon required to handle that?

Eliminating complex instructions like this is precisely what makes RISC fast. A RISC instruction can load from memory, or store in memory, but never both, and unaligned addresses are usually a fatal error. There is never any dangling state to deal with.

Instruction sets should be designed for compilers, not humans.

Re:It was still alive?

[haruchai]

Well, "kill off the Alpha [...] with the Itanium"...
Intel bought the rights for Alpha and discontinued it. That killed it.
Itanium would never have been able to compete with Alpha and replace it otherwise.

Alpha was great but when Pentium Pro came out and delivered good performance at a much lower price... that was the beginning of the end for Alpha.

The Alpha died when Compaq acquired DEC and dumped most of the engineering team who then joined some of the old Cyrix designers acquired by AMD and became the K7 engineering team that delivered the Athlon in 1999

Re:It was still alive?

[ShanghaiBill]

The other was the use of cheap laptop chips in rack servers.

Indeed. In the mid-90s, I often heard about the need for "big iron" in servers and data centers. Many people assumed that servers needed expensive high-powered CPUs and lots of memory, and this would be a lucrative market.

I realized this was bullcrap when I visited Hotmail in 1996 (a year before they were acquired by Microsoft). I expected to see a few slick looking million dollar servers, each filling a rack from floor to ceiling. Nope. Instead there was some cheap metal shelving from home depot, covered with cardboard from some old boxes cut up into squares. On each square of cardboard was a cheap commodity motherboard running FreeBSD, and a $2 SLA battery. The cooling was some cheap clip-on desk fans from Walmart. No wonder they were able to provide email for free.

That night I thought about what I had seen. If Hotmail could do it that way, anyone could. The next day I shorted Sun's stock.

Re:It was still alive?

[ShanghaiBill]

Is it just because they have the best fabs or designers or the most experience?

This is a big part of it. Intel has a huge market and can spread high NRE over millions of units. So they can devote a lot of engineering resources to each design iteration, and their fabs are fabulous (sorry).

- x86 has a pretty expressive instruction set which improves code density enough that more code can fit in cache than RISC-y architectures

This is only partly true. Original x86 code was dense, but extensions were tacked on that add prefixes to allow extended precision and extra registers. These made the code less dense.

Code has much better locality of reference than data, since a lot of time is spent in tight loops. So it actually isn't super important to have a really big code cache. The cache can be Harvard Architecture, so code and data are cached separately, and the code cache is read-only. Current x86 CPUs use separate "Harvard" cache for L1 (the one closest to the metal) and use a unified cache for L2 and L3.

Intel couldn't figure out how to make a compiler good enough

One of the early RISC principles espoused by Dave Patterson was that the chip and the compiler should be developed simultaneously. If the compiler guys need a key instruction, then the silicon guys add it to the design. If an instruction is rarely used by the compiler, then it should be eliminated and replaced in software with a slower (but infrequent) sequence.

A big mistake with Itanium, was that this didn't happen. The hardware was done first, and then the design was thrown over the wall to the compiler team. Instead there should have only been ONE team with compiler and hardware guys working side-by-side.

Another big mistake was that Intel tried to monopolize the compiler market. Only their own rather expensive compiler produced acceptable code. But at the time it was released, the server market was rapidly moving to Linux/FreeBSD and gcc was the FREE pre-installed default compiler. Not many people wanted to pay extra for a compiler. Intel would have been much better off if they teamed up with the FSF and worked hand-in-hand to have a gcc port working on day one, and using feedback from the gcc designers to influence the hardware design as well.

AMD did exactly this with their x86-64 design. They hired gcc developers and they worked closely with the hardware designers. When the chip was released, gcc was ready, and both Linux and FreeBSD were able to boot up and run on some of the very first systems.

Interesting future for HP-UX?

[ErichTheRed]

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.

I remember when...

[yorgasor]

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 :)