I don't know if getting Itanium to more people would've saved the platform because of their architecture. The first models had trouble with their memory performance, which was fixed in hardware. The compiler also needed to watch the instructions it outputted, as not putting out the right combination of instructions in order would leave CPU hardware underutilized. Instructions were very wide, causing more frequent cache misses as the cache was full of instructions that were shorter in other architectures. Furthermore, the compiler needed to emit certain hints for the branch predictor and other speculative execution units to function well.

I think the lack of availability certainly didn't help, but the architecture itself was probably the biggest downfall of the IA-64 platform. When it was introduced, the hardware was certainly advanced, but relied too much on software to get proper performance out of the chips. The product was doomed from the start.

Ampere will likely have entirely different problems bringing their architecture into the market, but I don't think Itanium ever stood a chance even if they'd sent out free chips to as many influential people and companies as possible.

There were many reasons why it failed but I think the combination of these two was more synergistic than it seems. Itanium’s designers made some very dubious assumptions about the kind of code they needed to run (businesses buy branchy code, not hand-tuned SPEC benchmarks) but then the systems cost considerably more than the earlier predictions and almost everything was much slower than predicted because few developers had access to a system to tune it and the best compilers were not free.

The architecture was probably a fatal mistake on its own (even if Intel had disbanded its x86 line, the “older” RISC processors outperformed, often substantially) but ensuring that almost nobody saw anything close to what performance it could deliver definitely made it fatal. If Intel hadn’t been greedy trying to charge for compilers, the gap wouldn’t have been nearly as bad.

> the best compilers were not free

This must have been a huge part. Maybe ICC could squeeze more MIPS per dollar out of Itanium than x86, but if GCC can't, people are going to not buy Itanium rather than buy ICC.

It was especially hard because compatibility was not a given and proprietary compilers of that era were notorious for having both compatibility issues and fragile optimizations where seemingly minor code changes had large performance impacts, especially when they’d basically targeted one SPEC benchmark. I saw multiple times where teams switched to GCC for compatibility/features and the performance impact on most other platforms was relatively modest.

> The compiler also needed to watch the instructions it outputted, as not putting out the right combination of instructions in order would leave CPU hardware underutilized. Instructions were very wide, causing more frequent cache misses as the cache was full of instructions that were shorter in other architectures. Furthermore, the compiler needed to emit certain hints for the branch predictor and other speculative execution units to function well.

I think that's the kind of issue they're talking about. If it had been easier for nerds in bedrooms to run Itanium, we'd've seen much better support for it in GCC etc. much sooner.

I don't disagree with your comment but I think “nerds in bedrooms” is possibly what works for tuning a particular open source project. GCC and other popular open source projects should have been a room full of Intel engineers because it's a hard problem and their revenue from their proprietary compiler & libraries was a tiny rounding error of the amount they spent building Itanium.

Back when I supported computational scientists, the total cost of the servers + compilers was so steep that even if everything had worked as well as the Itanium salespeople promised it would have needed to be many times faster to be worth the hassle of changing toolchains, especially since you had to pay up front for the hope that with a fair amount of work you'd at least hit the point of breaking even.

Later Itanium chips literally went right back to the "hardware JIT" (speculation, OOO, etc) they were trying to get away from in order to increase performance.

If Itanic had won, we'd still be basically where we are today from a hardware perspective, but with even less competition.

Reminds me of the AMD ARM server boards, that happened way after Itanium and they still repeated the exact same mistake.

Basically there was no way of getting your hands on them. They were interested only in "Serious customers".

If the market for something is already established it makes sense to stick to "serious customers".

If the market isn't established then you may need to get traction with the dreamers and misfits.

I see this happen with software projects, too. For example, I'm pretty sure that this same phenomenon is the main thing that killed Smalltalk.

I presume that the performance segment that Itanium was intended for is Intel's most profitable. So everyone who proposes to make server chips targets that segment, pretty much to the exclusion of everything else.

Having seen this play out a number of times I don't think targetting that segment and only that segment is a great idea.

I'm convinced sales forecasters don't actually understand how software ecosystems work.

From a stack perspective, you can't really go it alone anymore. The total necessary software universe is too large to rebuild on a reasonable timescale, and too expensive to rebuild by oneself.

IBM is about the smallest scale that can do this -- and even they're leveraging decades of effort.

IBM and Apple. Which makes Apple's Big Brother ad even funnier.

Although IBM is doing it x2, with s390x and also with POWER.

That sounds interesting, do you have a link for it?

‘Unplanned’ only because Intel learned absolutely nothing from the i860. Amazing performance on a hardware spec sheet, while real programs could never gain the benefit and only paid for the complexity.