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?

[TWX]

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.

Historically that's one of the things that always boggled my mind, Intel's instruction set had no protected mode until quite late, so programmers had to do some interesting things that often resulted in problems and the computer crashing anyway (IE Windows BSOD) or had to rely on a single-tasker operating system where it didn't matter so much; Motorola's chips had Supervisor Mode that was a protected mode, but Apple chose to ignore its existence when writing "System"/MacOS, where running multiple simultaneous applications in a GUI it would have been highly beneficial.

Just never understood that, especially when Apple had left the CLI world even before they completely dropped the Apple II line.

Re:It was still alive?

[jeremyp]

Supervisor mode in the 68000 was not, in any sense a proper protected mode. All it meant was that certain instructions were not available in user mode.

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?

[slew]

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.

Historically that's one of the things that always boggled my mind, Intel's instruction set had no protected mode until quite late, so programmers had to do some interesting things that often resulted in problems and the computer crashing anyway (IE Windows BSOD) or had to rely on a single-tasker operating system where it didn't matter so much; Motorola's chips had Supervisor Mode that was a protected mode, but Apple chose to ignore its existence when writing "System"/MacOS, where running multiple simultaneous applications in a GUI it would have been highly beneficial.

Just never understood that, especially when Apple had left the CLI world even before they completely dropped the Apple II line.

Supervisor mode in 68k was pretty much just an alt-stack pointer. Virtual memory support and similar protections was a function of the peripheral chips used in the system back in those days (not really highly integrated). The peripheral chip chosen by apple for the mac didn't support virtual memory and without such memory protection it probably wasn't worth the effort. Also you couldn't really run more than one program at a time anyhow.

By the time switcher and multi-finder features were added to finder, the shortcomings of this were obvious, but w/o virtual memory, it's hard to fix. SW constructs like handles instead of pointers patched over the situation (the same technique was used in Windows and other contemporary OSs to cover up for their lack of VM).

It wasn't until OSX where virtual memory was fully supported and that was much much later...

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?

[slimjim8094]

It's a common argument, but why does x86 continue to dominate, in performance and performance-per-dollar and performance-per-watt? (If not absolute-low-watts.)

Is it just because they have the best fabs or designers or the most experience? Those are probably true, but you seem like you know what you're talking about so I'd like to float a different theory:

- x86 has a pretty expressive instruction set which improves code density enough that more code can fit in cache than RISC-y architectures
- Modern processors are so fast and have so many cores that the RAM is often the bottleneck, especially with NUMA. Managing the cache is more and more important, so code density pays increasing dividends
- The standard argument is that the compiler can make better optimization decisions, but is that really true? Intel's engineers are really really good and the optimization they're able to do in generating the microinstructions (and potentially different microinstructions for identical instructions!) that's informed by their intimate knowledge of that specific die are just too powerful to beat the compilers, which don't know the chip as well as the designer.

It's a bit like the native code vs JIT VM debate - the VM folks argue that the VM knows more about the program since it's at a higher level and can make smarter choices. I wonder if CISC is analogous to VM bytecode here.

I should also note the irony of essentially saying "the compiler makers will figure out how to make the dumb chip fast" on an article about Itanium - that's a large part of why it failed, even Intel couldn't figure out how to make a compiler good enough to really make use of the chip. Of course Itanium wasn't RISC, but still.

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.

The Itanic has sunk

[isdnip]

It never was a very good architecture, but there was a VMS port to it.

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.

Re:Interesting future for HP-UX?

[motorsabbath]

Take it back - hpe.com .....

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

Dupe

[heson]

Dupe from many years back. The Itanium is well dead and buried since long, the zombies were only for extra fooled customers.

Re:Death by compiler!

[Tough Love]

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.

And because it was inferior.