News: 1612178052

by both people still using it

I've gone through every step of this industrial debacle:

- mid-90s with HP people announcing proudly they were dropping PA

- 2000s years with IA64 being an HP-UX only CPU, with a couple of bozos installing Linux (why would you do that on so expensive boxes anyway ?)

- 2000s again, with HP-UX being utter shite (mostly the storage layer) vs. competition, every IA64 CPU being many years behind any X86

- late 2000s with HP-UX 11iV3 being the first (and only I think) version of HP-UX having a good storage layer

- the Oracle lawsuit revealing HP had to pay millions to Intel for Itanic life support, making every customer understand why the blip this platform has so insane support costs

With all the above, surely the platform was doomed. I'm actually surprised they didn't pull the plug like 5 years back ! There probably were quite a lot of rich and captive customers, here. Probably MPE played a role, as I know at least a couple of companies that were still using it not too long ago.

Bozos? You mean like Rolls Royce? And the hundreds of SGI Altix supercomputers?

These ran SuSE Linux and they weren't constructed in a shed by some wild eyed open source evangelists.

Pretty sure the "bozos" remark was meant ironically. The Itanic VLIW arch was great at regular FP64 computations and the Itanic SGI Altix had some limited success, but for apps like databases, SPARC was much better. But SPARC didn't save Sun and Itanic didn't sink Intel and HP, proving that big companies can f* up and survive, while smaller companies walk on a knife's edge despite better tech.

Itanium was a great architecture for CFD work and meshing.

Not only HP machines - SGI Altix were constructed from Itanium processors. NUMA machines which could address huge amounts of memory.

When a blade was replaced in an SGI Altic, when the machine was rebooted the blade would join the system.

Of course there were export control regulations - Uncle Sam did not want $nation to make supercomputers by buying up spare blades..

So when a blade was replaced the SGI engineer had to phone up a number in the USA and be given a code number to type in at boot time.

Or the blade would not be recognised.

While AMD64 Opteron killed the market for Itanic, it was the multi-core approach that killed its projected performance advantage, leading to a change in software design. The remaining case for very long word instructions use-cases was killed by GPGPU.

It was no just a commercial failure, but an architecture: good riddance to bad rubbish.

64 bit XP for Itanic was very short lived, killed off years before 32 bit x86 XP.

It was the 2nd 64 bit Windows. The first was a version of NT4.0 for the 64 bit Alpha.

DEC and demise of the Alpha wasn't really anything to do with the doomed Itanic. That was a more complex thing and also it was great pity Intel got the DEC StrongARM and that HP got Compaq and DEC.

Nearly 11 years ago:

https://forums.theregister.com/forum/all/2010/04/05/microsoft_pulls_plug_itanium/#c_733422

From the ground-up, Windows NT was built as really really portable.

Proof are its 4 initial platforms:

- 32b x86 (nobody had ever though of a 64b x86 at that time

- 64b Alpha

- 64b MIPS (I got one at work!)

- PowerPC (I saw references inside doc., even possible one of my colleagues used one) I do not remember if it was 32b of 64b

Itanium came later.

Pretty sure PPC was 64b - we had one, running Windows even - before we switched it to AIX.

NT 4 was only ever 32 bit, and that was all that ever ran on the powerpc, mips and alpha. There were 64 bit development work on the alpha, but it was canceled before release, so only itanium got 64 bit windows released initially to be joined by x86 later, and eventually arm.

As for being portable, well maybe for Microsoft code, but it only works on little endian, which certainly prevents some CPU targets from ever running windows. Only the fact powerpc, mips and arm can run both ways allowed windows to be ported to them, since they always run them in little endian mode for windows. Alpha and x86 of course were only ever little endian. Motorola 68k of course would never have a had a chance to run windows.

My impression is that there was a lot of leverage applied by Intel to kill of the Alpha. That leverage could be inducements for HP to buy other intel processors cheaply or backhanders to senior execs.

The Alpha was superior at that time and had a large following.

We got a brand new, recently launched Compaq AlphaServer ES40 at work to replace a VaxCluster 4000. As planning/doing the migration would take a few weeks, it was sitting doing nothing so as an experiment I ran Seti@Home for OpenVMS on it for benchmarking. It was the 7 fastest computer in the world at that time.

My impression is that there was a lot of leverage applied by Intel to kill of the Alpha. That leverage could be inducements for HP to buy other intel processors cheaply or backhanders to senior execs.

Except it wasn't HP which killed off Alpha, the decision and announcement was made by Compaq well before the merger talks with HP.

A long way prior to this, back when DEC were still DEC and had great plans for Alpha's future.

So a long way back.

HP bought container loads of Intel processors, but not the X86 kind. These processors were destined to end up in printers which HP sold a lot of, therefore there were of lot of processors involved here.

Intel were killing off the i860 line, so the printers need to find a new processor, the x86 line wasn't suitable, it would have made the printers far too expensive. One possible solution was a level 0 PA processor, HP weren't going to be in the fab business for this. So Intel and HP started to talking and HP mentioned the PA3 project as being their intended next generation. PA2 was the 64bit version, oh and the level is nothing to do with the version BTW, the PA3 VLIW project had kicked off at about the same time as the PA2 project but was a much longer term venture.

Intel wanted a way forward, RISC was kicking its butt from a performance perspective and there was this damn AMD problem with someone else being allowed to make x86 processors. What HP were investigating looked like the answer to their problems, and Intel taking on much of the cost of development and all the fab'ing side was the answer to HP's problems. So they got into bed and Itanium as join venture happened. On the first generation (not designed by HP) was massively late to market, in fact at one point it looked like the HP designed Mk2 was going to overtake it.

I'm less aware of the details on the DEC/Alpha side, but my understanding was that there was a legal dispute between DEC and Intel and to make this go away Intel bought a bunch of assets off a cash strapped DEC, this included the Alpha development team. People don't like being sold, so they buggered off en-mass to AMD and were responsible for the AMD64 bit x86 processors.

Intel had never intended there to be 64bit x86, they wanted x86 to die so they wouldn't have to share the market place.

Most manufactures eventually got on the Itanium bandwagon at least for a while. The lateness of Merced killed a lot of this.

As soon as it was clear that Intel was not really behind it, it had little chance in the x86 world because it was shit for x86 code. And, as long as Intel kept producing x86 chips, they had little incentive to favour another archictecture.

x86_64 meant that people could have their c86k and 64t it without feeling the need to replace every bit of software on their systems. That was always going to be a big ask in the pile it high sell it cheap world of x86.

Back in the day I read up quite a bit about the Itanium architecture. They had a lot of excellent ideas. There was one problem back then: There were _too many_ excellent ideas; creating a compiler making use of all of them was very, very hard, and making a JIT compiler making use of any of them was even harder.

There is a bigger problem right now: All their great ideas have better solutions now in modern chips. Itanium could read three instructions in a package, your iPhone processor can read 7 to 9 depending on the model. Itanium had some good tricks to avoid the need for Out Of Order processing, your iPhone processor can handle a few hundred out of order instructions. Itanium had some pretty poor hardware to execute x86 code, much slower than an Intel processor, and much slower than a current ARM processor with the right software.

Having left the whole server arena about ten years ago I thought Itanium would have died a looooong time back so I was quite surprised to learn it was still available. Especially when the Xeon has always done a decent job.

I wonder how much of distraction continuing Itanium development for so long was for Intel.

Technically available doesn't mean alive. It was mostly dead nearly 12 years ago and no-one could persuade Miracle Max to resuscitate it.

They people that were buying this type of processor were stipulating that it had to be commercially available and supported for 10 years. And these companies are not ones you would mess with -even if you were Intel.

Not so much a distraction for Intel as it was for HP Enterprise what with the HP California crowd - such as Whitman etc - waiting in vain for what she even termed "proper computing" to return, which of course it never did. Meanwhile ProLiant - which by implication had to be "improper computing" - was paying all the bills ....

Actually, I meant Livermore rather than Whitman.

Always been curious to try the steaming brick pile out. 2nd hand bits never really got to throwaway don't care.prices unfortunately.

I'd be even more interested in trying out event incarnations of SPARC, but ludicrous pounds.

Out of interest, I checked if NetBSD still supports Itanium, and surprisingly even it has dropped it, or never had (The II Tier table has "none" for the latest release of IA64). Curious, because NetBSD supports many platforms you can find only in a museum, or a fleamarket with a particularly slow turnover...

Considering how the Linux kernel still supports things that are way older and deader.

Well, IA64 has been a dead ghost walking since its first cores hit the market. So, calling it only recently deceased may be an underestimate of how dead the platform is.

The ghost has been haunting the house for quite some time. So killing it in the Linux kernel can be considered mercy to all other architectures.

And that is a bloody shame.

I used an Itanium as a bottle opener once. Bad idea, that thing had *very* sharp edges and my hand was bleeding quite a bit. Cannot recommend.

On a more serious note: I tried it for integer computations and it sucked, as in elephants through a straw. The CPU was rumored to be at 70k dollars, by the way.

There were seriously large pieces of silicon inside, determined using a Dremel on the bottle opener mentioned above. Sadly I left it on my table and the next day it was gone, a cleaner had thrown it away.

I used an Itanium as a bottle opener once. Bad idea, that thing had *very* sharp edges and my hand was bleeding quite a bit.

So you can claim first hand experience on the origin of "bleeding edge".

> "bleeding edge".

LOL, yeah. Sadly also hurt like fuck.

It's sad that actual 64-bit processor architectures haven't taken off in the mainstream. Between Itanium, DEC Alpha, Sparc, Power (though Sparc & Power9 is still around) and I'm sure there are others, the market had a future that could have been ramped up much like the current (polish a turd) x86 architecture (which is actually IA-32 for Intel and RISC64 for AMD via NexGen). Now with x86 we are very incrementally increasing actual performance and we could have seen a bigger leap by now. Of course that requires everyone to adopt 64-bit processing and a lot of code would have to be redone no matter where you run it. It's not just 64-bit memory addressing which didn't necessarily need such a major overhaul.

Oh well, such is life.

Unfortunately it is much easier to switch over a few programs at a time to 64 bit x86 while keeping your existing 32 bit code running using x86-64 than it is to migrate everything to a new platform all at once.

At least AMD did a better job cleaning up a bit while adding 64 bit than intel has ever done in the past when extending the x86 architecture. x87 had to die and adding more registers was desperately needed. AMD did a very good job on the polishing of intel's turd.

I'm curious why you think x86-64 isn't an 'actual' 64 bit processor. It's not just 64 bit addressing, it has 64 bit GPRs and ALUs too, just like MIPS-64, Sparc 64, PowerPC 64 or indeed AArch64.

And as, indeed, AArch64 shows quite clearly, the ISA isn't the main constraint on increasing performance; we would not all be suddenly using 10GHz CPUs if MIPS had won out over x86.

Thumbs up for the excellent technical discussion.

I'm not implying that clock cycles have anything to do with this. In fact, I'm suggesting exactly the opposite. The core processing on x86 is still 32-bit which is why everyone in the world didn't have to recode their app in order to work at all on x86-64.