Itanium was created precisely because HP thought it couldn't keep PA-RISC competitive. So they threw in with Intel to create the next great server architecture.

As an aside, Merced too forever for Intel to tape out. Part of the agreements between HP and Intel was that they needed to ship chips for HP. As a result, Intel had to fab some of the last PA-RISC chips due to the schedule slip and contractual obligations.

I worked on some Itanium system software once upon a time.

Timing was at least part of the problem with Itanium. Arguably, had Merced (or, ideally, McKinley) shipped while the great Internet buildout was going on, Itanium might have made it over birthing pains before the dot-com crash and then been in a position to ward off Opteron and AMD64 when those arrived.

I could argue it was doomed from the beginning as well for various technical reasons given how the industry evolved. But there's at least an argument that better time to market might have been enough to get established as a dominant 64-bit architecture.

Being a couple years late definitely was bad but they also completely blew the performance, especially for ia32 compatibility. Shipping on time would have made the performance gap less bad but I rarely saw it being competitive with what would have been the competition at that time even before you factored cost in. Unless your workload was just Intel’s hand-tuned assembly it was usually cheaper to buy 2 x86 boxes and pocket the difference.

You're absolutely right, hence my hesitancy. IA-32 emulation performance was one particular weak spot. A fellow analyst at the time said something along the lines of "Itanium's IA-32 performance was not only not in the ballpark; it was not in the parking lot outside the ballpark."

Itanium was also, in many ways, designed for a world where ILP, rather than TLP, ruled. That distinction wouldn't become terribly important for a few more years but it would have eventually. Intel made a number of decisions in this vein. See also NetBurst Architecture. (An Intel exec told me, at some point after it had become obvious that multi-core was the future, that Microsoft had really pressured Intel to go down the few/fast cores route.)

I can see the connection. Microsft was even more vulnerable there than Intel.

If we switch from the "Every year the clock rate goes up 30%" model to "50% more cores every year", you're going to trigger the "recompile the universe" event. This is an esistential-level threat for the Microsoft of 15 years ago.

Microsoft's biggest selling point for years was the backwards compatibility. Keep running that old software forever, and the magic of Intel running the clock up means it still gets faster every year.

If that train stops, you may well think "if I have to rebuild anyway to support many-cores, why not do so on Linux?"

Because not everyone is writing CLI POSIX apps in C and C++.

Intel initially didn't plan on having fast IA-32 performance. The IA-32 part of the chip was called the "IVE" which was short for the "Intel Value Engine." The thought was that it was enough for the chip to boot in IA-32 mode to be compatible and it was expected that you would set up system state and jump to 64-bit mode as fast as possible. So really it was just meant for compatibility. I imagined it was just a dusty corner of the chip using some old 486 core to take up the least amount of space.

>"Itanium was created precisely because HP thought it couldn't keep PA-RISC competitive."

I'd be curious to hear why that had that outlook. Wasn't HP still doing gangbuster's business at that point? Or was it something else besides having the financial resources?

They thought that they couldn't compete in the future because they didn't have the fabs to do it. They thought that by throwing in with Intel they could make headway into the high end server space. Additionally, everyone was using Sun machines to develop on (this is before the stupid-long delays with UltraSPARC). They also thought that the future was code on Windows workstations connected to HP big server iron. That was Rick Belluzo's contribution to killing HP-UX workstations. He left after awhile to go try to sell the same sauce to SGI. Finally the wound up at MSFT.

Fast-forward and now Linux is dominant and who even uses HP-UX or the other proprietary UNIXes?

I wonder what the future of hpux is? Tried to search but couldn’t find anything other than future plans to run hpux as a Linux container which sounds like marketing since hpux isn’t something to run as a Linux container

Still, I wish HP hadn't given it up and maybe opened it up like SPARC. PA-RISC was posting some impressive numbers into the aughts when they were just multi-coring "old" designs.

Fun story: up until a couple years ago, my employer ran the entire company (manufacturing) with software running on a PA-RISC mainframe. I wish I could have taken that machine home when they took it offline.

I don't know a lot about PA-RISC, can you what was it about that ISA differentiated it?

It didn’t get hung up on RISC purity and introduced a series of instructions that kept code sizes down: single instruction Indexed Loads (normal and scaled), single instruction Address updates, bitfield operations, FMADD, subword operations (making decimal math ops faster), a bunch of branch path instructions and a handfull of others.

It had 32 64bit FP registers that could also be used as 64 32bit registers or 16 128bit registers. For the time this was novel.