Slashdot Mirror
HP's NonStop Servers Go x86, Countdown To Itanium Extinction Begins
An anonymous reader writes "HP has been the sole holdout on the Itanium, mostly because so much of the PA-RISC architecture lives on in that chip. However, the company recently began migration of Integrity Superdome servers from Itanium to Xeon, and now it has announced that the top of its server line, the NonStop series, will migrate to x86 as well, presumably the 15-core E7 V2 Intel will release next year. So while no one has said it, this likely seems the end of the Itanium experiment, one that went on a lot longer than it should have, given its failure out of the gate."
Not a single major hardware or device maker seems ready to support Linux on non-Intel architectures. Intel, MS, HP, Cisco etc. are part of the TCPA alliance; even Linux on ARM based servers have taken a very long time to arrive.
If you keep throwing chairs, one day you'll break windows....
given its failure out of the gate.
For a multibillion dollar industry, "failure" is a rather strong term. It may be declining, but it topped over $4.4bn a year at one point. That's probably bigger than AMD.
SJW n. One who posts facts.
Earlier this year HP announced the end of the line for VMS. That was certainly connected with the Itanium retirement as well.
"Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana
I work on a product that supports Itanium, and we have a few customer that are still using Itanium servers, who knows why. We just discovered that unless you get the top-tier developer subscription to Microsoft Visual Studio, you don't get Itanium compilers.
PHEM - party like it's 1997-2003!
Based on the amusing idea that compilers can more easily determine which instructions can be executed simultaneously at compile time than the CPU can at run time...
Years ago one of my friends had the misfortune to have to write code generators for a CPU which required the compiler to determine whether a previous pipelined instruction had completed before reading the result because there were no interlocks to stall the CPU if it hadn't. He could have told Intel a thing or two about trusting software engineers to schedule instructions rather than CPU designers.
Let me count the ways
And there was much rejoicing!
And nothing of value was lost.
For those saying it wasn't a failure you must look at what Intel intended Itanium for. If they had succeeded Intel would have owned the 64 bit CPU realm on the desktop with a proprietary architecture effectively eliminating any competition in the space. To succeed they had to get all popular software including Windows to be rewritten for the new processor. This was a daunting task and few were ready at the time to make the switch to 64 bit. AMD introduced the Opteron in 2003 with their 64 bit extensions for the existing x86 architecture which allowed the reuse of the 32 bit code in existence. AMD's x86-64 was well received and Intel ultimately adopted the architecture in their own processors. So yes the Itinaium failed to succeed in its intended task despite lingering for over a decade.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
I am extremely disappointed that this Register article does not use the word Itanic. Not even the (currently 8) reader comments. I expected higher standards from such an organisation as El Reg.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Unfortunately it became a legend for all of the wrong reasons. Billions of dollars have been sunk into it over the years and many lawsuits have been filed over it demise by vendors desperate to get out of it or force another vendor to stay in it.
http://www.eweek.com/servers/hp-to-seek-4-billion-in-damages-from-oracle-over-itanium/
http://news.cnet.com/Allies-pledge-10-billion-to-boost-Itanium/2100-1006_3-6031773.html
http://www.masslive.com/news/index.ssf/2013/09/hudson_intel_plant_closing_wil.html
Unfortunately sales never came close to the billions of dollars that have been sunk into it, and it has been that way for years:
http://www.theregister.co.uk/2005/02/28/itanium_04_sales/
http://www.wired.com/wiredenterprise/2012/02/hpearnings/
http://www.zdnet.com/photos/charts-mining-itanium/21115
I'm sure someone has a comparison of how much money has been invested compared to how much money has been made in sales. I might be mistaken, but from what I've been reading from the beginning Itanium has never come close to breaking even for hardware or software sales. Certainly companies like HP and Oracle spent millions of dollars on their lawsuit trying to get out Itanium.
Itanium has always been nothing more than a desperate multi-billion dollar effort to break free from the chains of x86.
Looks like it's the end of the line for OpenVMS as well.
I would pay good, American money, to have OpenVMS open-sourced instead of just languishing like other DEC OS's. Why can't RSTS/E or RSX-11 be free? What could that possibly cost HP? Same with OpenVMS at this point. It's a great system, and I would love to see it available to average joes.
Someone who isn't as lazy as I am should start an "Open Source OpenVMS!" petition.
...but it's being eaten...by some...Linux or something...
I'm sure HP has been staring this one down forever, saying "We sunk all this money into Itanium, there's no way we can abandon it." In fact, if you look at the documents from HP's lawsuit that Oracle helpfully put up on their website, you can see internal discussions of their intention to port HP-UX to x86 and the fact that they're basically paying Intel to keep developing Itanium processors for them.
Itanium was an interesting idea, and the only way to get 64-bit non-Sun, non-IBM hardware until the Opteron came out. But it's a really good example of a technology hanging on way past the point where it's relevant.
I wonder if they've inadvertently sent OpenVMS to the old folks' home by doing this...unless they're planning to port OpenVMS to x86. I know there's plenty of legacy OpenVMS stuff out there, but who knows if those customers would be willing to finance a port by buying machines from HP?
I also wonder if at least some of the ProLiant line is going to get that awesome RAS (Reliability, Availability, Serviceability) that NonStop and the Itanium boxes have. That would be cool.
Did Itanium have any performance advantage over x86_64? It certainly didn't have a price advantage, if anything it was horrendously expensive for the performance you got.
We only have a SINGLE Itanium based server here, purchased more out of curiosity than anything else, years ago when the platform was new. There's nothing special about it whatsoever.
I keep thinking the platform should have been declared a failure years ago, unless there was some specific thing it was really good at that I'm not aware of...
I'm not really sure where you're going with that one, with dual-stack any system that can run IPv6 can also run IPv4.
Other then it pushed Alpha in to AMD's hands giving birth to the Opteron, Intel snatched defeat from the jaws of victory there.
Leaving us with the crummiest architecture of all contenders as the market leader.
But why should hardware have it better than software?
Until there is a supported COBOL environment in Linux, HP-UX on Itanium will be around for a long time.
I work in the power industry, and we use some very specific applications that are only available on HP-UX and AIX. HP-UX is by far their largest install base.
These apps are used by the power plants/coal mines for everything. As you'd expect, there are very few applications that are certified for use by the power industry that meet the regulations. The one we use will begin supporting LDAP instead of NIS next year.
There's no incentive for new players in this software market due to the small number of potential customers and the massive trust curve they'd have to meet to make somebody switch.
We're one of the reasons there's a pretty long road map for Itaniums and HP-UX.
My mom says I'm cool.
when HP/UX x86-64 port is out, then Itanium2 will be dead
Ah, classic.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
What are the people at Intel thinking? Where did they get 15-core from? Are they making a 16-core CPU knowing there's always going to be one bad core? Why not make a 17-core CPU instead? 15-core seems odd, it's always been 1,2,4 or 8 cores AFAIK.
Get free satoshi (Bitcoin) and Dogecoins
HP had Intel put a ton of RAS features that are needed for the Nonstop and Superdome lines into the Itanium chip, in addition it ran modified 64bit code originally targeted at Alpha, MIPS, and NonStop processors, something which couldn't be done with x86. Basically it was a way for HP to jettison all the legacy hardware from their acquisitions over the years and merge them into one "commodity" chip that they could buy from Intel.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
IA64 started as an HP Labs project to be a new instruction set to replace HP's PA-RISC. VLIW has a hot topic around 1995. HP Labs was always proposing stuff and the development groups (those making chips/systems) ignored it, but for some reason this had legs.
The HP executive culture is: HP hired mid-level executives from outside. They would then do something big to get a bigger job in another company. A lot of HP's poor decisions in the last 20 years can be directly traced to this culture. And there was no downside--if you failed, you'd go to an equivalent job at another company to try again.
So enterprising HP executives turned HP's VLIW project into a partnership with Intel, and in return HP got access to Intel's fabs. This was not done for technical reasons. Intel wanted a 64-bit architecture with patents to lock out AMD, and would never buy PA-RISC. So it had to be new. HP was behind the CPU performance curve by 1995 due to its own internal fab not keeping up with the industry due to HP not wanting to spend money. So HP could save billions in fab costs if Intel would fab HP's PA-RISC CPU chips until IA64 took off. So, for these non-technical reasons, IA64 was born, and enough executives at both companies became committed enough to guarantee it would ship.
For a while, this worked well for HP. The HP CPUs went from 360MHz to 550MHz in one generation, then pretty quickly up to 750MHz. I thought IA64 would be canceled many times, but then it became clear that Intel was fully committed, and they did get Merced out the door only 2 years late. IA64 was a power struggle inside Intel, with the IA64 group trying to wrest control from the x86 group. That's where the "IA64 will replace x86" was coming from--but even inside Intel many people knew that was unlikely. Large companies easily can do two things at once--try something, but have a backup plan in case it doesn't work.
But IA64 as an architecture is a huge mess. It became full of every performance idea anyone ever had. This just meant there was a lot of complexity to get right, and many of the first implementations made poor implementation choices. It was a bad time for a new architecture--designed for performance, IA64 missed out on the power wall about to hit the industry hard. It also bet too heavily on compiler technology, which again all the engineers knew would be a problem. But see the above non-technical reasons--IA64 was going to happen, performance features had to be put in to make it crush the competition and be successful. The powerpoint presentations looked impressive. It didn't work out--performance features ended up lowering the clock speed and delaying the projects, and hurting overall performance.
Itanium would have allowed Intel to dump all the x86 baggage and move the world to a Brave New Shinier CPU that was 64-bit and appeared to offer substantially better performance.
And it would have made them sole supplier for the mainstream CPU market, taking out AMD and the other clone x86 makers.
Unfortunately, the early compilers sucked and x86 emulation really, really, really sucked, so no-one with a big investment in x86 software was going to make the switch. If I remember correctly, it was also years late, so performance that would have been impressive at the initial release date had become 'meh' by the time it actually hit the market.
For those who don't remember.
NonStop used to be Tandem, whic was acquired by Compaq, which got acquired by HP.
Tandem had proprietary hardware, proprietary operating system, and even proprietary languages. It was big in high availability stuff, like bank networks running ATMs, ...etc.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
I thought that the Registed actually coined that term?
The thing I loathe most about the Itanic is how it sunk 2 or 3 better CPUs before it - PA-RISC, MIPS V and Alpha. Compaq/HP should have left NonStop on MIPS and VAX on Alpha, and never gone the Itanic route w/ them. Heck, even Linux largely (except Debian) has abandoned the Itanic, and only FreeBSD, of the BSDs, did an Itanic port (I'm not sure that even the much ported NetBSD or OpenBSD has been ported to it). There is even less reason for VMS or NonStop to have gone Itanic.
Two things the Itanic can be good for - supercomputing, and a test bed for Inferno/Plan 9.
Linux ports of just about every major CPU exists - SPARC, MIPS, Power/POWER, PA-RISC, Alpha, Itanic, in addition to x64. Main issue is that of these, Alpha, PA-RISC and MIPS V are dead, and of the remainder, current Linux distros have dropped support. Red Hat, for instance, supported SPARC at one time, but no longer does. IBM supports Linux on POWER, which is why it's there. HP pushes mainly HP/UX for Itanium, aside from legacy customers who bought Integrity servers for VMS or NonStop. As a result, most Linux distros are x64 only.
If one has an Itanic box - the only one I know of is the Integrity line from HP which they are converting now to x64 - then the only choice as far as Linux goes is Debian, which never retires any CPU. Or, if one prefers the BSDs, one can go w/ FreeBSD. Other than that, w/ the Integrity, one can go HP/UX, and w/ other Itanic boxes, such as ex-SGIs, one is stuck w/ Linux or FreeBSD.
Ditto that comment. I really hate the fact that HP gets any credit for NON-STOP, Tandems baby, or VAX and Alpha, 2 of the 3 great things that Digital brought forth into this world, the other WAS Alta-Vista. The only thing HP ever did well was printers and that time has LONG since passed...
Note : I spent several years supporting all of the above machines and may be a bit biased.
errr....umm...*whooosh* *whoosh* Is this thing on ?
Once this line goes x86, how are they different from anybody else - their own ProLiant line, or top end servers from IBM or Dell? Also, are they planning to migrate HP/UX to x64, or will they simply migrate HP/UX customers to Lintel (Linux on x64)? If it's the latter, their customers have probably beaten them to it by probably more than a decade
So once this line is x64, there will be nobody who's making Itanium servers, will there? Or will it be a China only CPU - w/ customers like Huawei? So does that mean that Intel will finally put the Itanic out of its misery?
Those were 2 different MIPS line. MIPS V was what went into servers from SGI, and got replaced first w/ Itanic, and then w/ x64. The MIPS that goes into high-end embedded or even low end embedded is MIPS IV and III (R8000 & R4x00)
Everyone seems to be cheering at this event, but it seems to me HP just wants to close down some of its NonProfitable(tm) divisions.
First VMS, now this. This won't end well.
Well, it may be multi-billion-dollar industry, but it spectacularly failed to meet its sales projections. My absolute favorite Itanium sales chart can be found here. Granted some of those initial projections were crazy stupid. But it fell short of even the much more modest, revised projections from 2002 and 2003.
Damned shame that they killed Alpha and with that move doomed VMS. The Itanium port didn't help expand the VMS base, since there wasn't enough support to VARs to keep the support for VMS in applications. There are only two viable OS choices now. Windows and Linux/Unix. (And the Unix part is weakening over time due to costs vs. Linix).
I fully agree w/ this. Compaq would have done better keeping the Alpha, and HP should have sold Alpha to someone other than Intel. Alpha would have been a perfect platform for 64-bit Windows, in addition to OpenVMS. HP turned out to have made a bad call in deciding to migrate from PA-RISC to Itanium: if PA-RISC was expensive to design & maintain, it would have been cheaper for them to simply sell it to Intel (which was already fabbing it anyway) and ask Intel to design & make it for them. Intel could then have competed at the high end against POWER & Alpha w/ PA-RISC, while still having x86. They wouldn't have had to license x64 from AMD, but instead, since PA-RISC was already well supported by HP/UX & Linux, they could have either promoted PA-Linux or gotten Microsoft to port 64-bit Windows to the platform. That way, they would have gotten a successful architecture exclusively their own, w/o the failure that came w/ the Itanic.
Precisely, and as PlusFiveTroll pointed out below, any system can be dual stack and run both IPv6 & IPv4.
Hah, MIPS is still very much alive. Well, not on desktop, but still...
Ezekiel 23:20
Alphas for VMS were sold until 2007, so plenty of big companies will be using non-Itanium OpenVMS for about 10 more years
Your forgetting RPN calculators and instrumentation
No, it didn't. Reason HP went w/ it was the perception that since RISC was faster than CISC, which got proven by Intel building in all sort of RISC based concepts into the Pentium, which included moving some of the complexity of a CPU to compilers, VLIW could be faster as a result of moving all of the complexity of a CPU - even a RISC CPU - into the compiler.
Main issue w/ that, even before the project started - was the fact that in VLIW, since everything - register renaming, speculative execution - is moved from the CPU to the compiler, w/ every CPU generation, unless all you do is bump up the GHz as well as the cache, any change to a CPU would necessitate recompilation of existing software to get any performance improvement: running existing binaries would show no improvements whatsoever. That alone should have killed the idea.
As it turned out, RISC was an optimal spot b/w CISC & VLIW. While Pentium adapted a lot of RISC concepts like superscalar execution, expanded register sets and branch prediction, Itanium too smuggled in RISC practices like Register Renaming, which is supposed to be gotten rid of in VLIW. In the meantime, RISC CPUs such as Alpha 21364 & POWER adapted some VLIW concepts such as smarter compilers that extract more parallelism, MIMD operations and so on. So HP would have done better in selling Intel the PA-RISC and Intel improving that rather than starting out w/ this VLIW concept.
I said MIPS V - the R10000, R12000 and everything else in that line. Those CPUs were only used in SGI's & other servers. The ones that go into routers, or PlayStations or Nintendos are MIPS III or IV CPUs, afaik
Is Windows 2003 server on Itanic native, or does it run under x86 emulation?
Yep, this. HP RPN calculators were, and often still are, outstanding. And I remember as a u/grad on work experience running an aircraft engine vibration test using HP FFT analyzers back in the 80s. These bits of kit would still look modern and sexy today, back then it was like they'd dropped through a wormhole. Of course each one cost more than I paid for my first house...
"Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
R10000 and R12000 were MIPS IV, not MIPS V. Whatever was scrounged from the canceled MIPS V can only live in MIPS32 and MIPS64 implementations.
Ezekiel 23:20
I would attribute the failure of MIPS as well which was used in workstations to Itanium.
Itanium was planned before 64-bit versions of x86 arrived. So you've got the question backwards: what were advantages of x86_64 over Itanium?
Itanium was trying to ditch x84. Just like many people, Intel also hated the x86 and hated being tied down to it with a never ending backward's compatibility ball and chain. Meanwhile RISC was doing great, and all the decent workstations out there were running on RISC chips whereas x86 was stuck on lower end PCs, and compilers were getting good enough to get decent performance out of RISC as well. So that was the plan: get a "modern" CPU and remove reliance on the old stuff that wasn't scaling up.
What happened though was getting the 64 bit extensions to x86, allowing larger memory spaces without breaking compatibility with Windows, plus advances in Pentium allowed them to get RISC like performance under the hood while having a CISC decoder on top. Over time the 64-bit extensions expanded and became more useful as well, until there was a full 64-bit architecture. The drawback of course was that it's essentially a 64-bit system with a 32-bit leftover kludge bolted on, exactly the same as the 386 was a 32-bit system with a 16-bit kludge for compatibility reasons. And the IA64 architecture still retains a lot of design decisions that wouldn't make sense in a designed-from-scratch system.
Itanium didn't fail because it wasn't as good a design, it failed because it wasn't a series of small incremental improvements. Thus lots of development costs up front which are necessary for ANY new high performance design. After some time that funding slows down. Meanwhile lots and lots of funding is still going into continuous small improvements to x86 style chips, and Intel is stuck with it.
IPv6 is certainly not the only way forward and is overkill (64 bits for your local network?) for replacing IPv4 as well as being too complex. The correct solution is compression within the current 32 bits - that way you can fit many more than 4 billion addresses. I hear there's a google project on this.
I thought you might be trolling because you can't map a 128bit address space into a 32bit space without collisions when you have >32bits of unique information to store. It looks like there is a patent on this: http://www.google.com/patents/WO2013066969A1?cl=en registered to http://en.wikipedia.org/wiki/Cable_Television_Laboratories,_Inc. not Google. They are a consortium that develops cable modem standards (DOCSIS).
The patent is for a form of NAT which handles 1-1 mapping and allows for collisions with actual/virtual ipv4 addresses by remapping those as well. Each IPv4 device behind the cable model would get a unique IPv6 that the world can see and would see external addresses as a translated IPv4 address. Apparently it is expected to break down when the number of unique connections exceeds 33K/day. Looks like a good transitional form of NAT for consumers who are still running older systems that don't support IPv6. It is not a general solution that could replace IPv6, in fact it requires IPv6 at the ISP level.
Alpha and MIPS are completely different than IA64. Alpha was a true RISC chip with a fixed 32-bit instruction length, superscalar, out-of-order execution. IA64 was a VLIW chip with in-order execution that relies on the compiler to do anything efficient.
HP made a fatal mistake cancelling PA-RISC and Alpha in favor of IA64. The could have picked either of the other two as a successor, and have been better off as a result. Instead they chose a dead-end, probably because (at the time) it looked like the entire hardware industry would go that way. Before SGI, IBM, Dell and others backed out.
MIPS V apparently never actually hit silicon. R10K, R12K are still MIPS IV. (I have some SGI kit with those, a couple of the purple Indigo2 IMPACT systems, and an O2.....)
If you're thinking MIPS64, well, you can find that in embedded devices, routers, etc. Look for Cavium Octeon processors.
See https://en.wikipedia.org/wiki/List_of_MIPS_microprocessor_cores for which silicon is MIPS64.....
Does anyone know the relative installed base b/w Vaxen, Alphaservers & Integrity servers running OVMS?
HP didn't want to be in the chip business, which is why they sold the IP and engineers to Intel in exchange for long term contracts to produce Itanium. I very much realize that Itanium is vastly different from either PA-RISC or Alpha, but code originally written for either could and was ported to Itanium, something which could not be easily done with x86 (remember this is pre-x64 aka AMD64). You say it was a fatal mistake, but the HP Enterprise business group still brings in billions a year more than a decade after they jettisoned the baggage of making chips, and now they get to move the customers who are still with them over to x64 which means they can stop paying Intel whatever fees they are paying to keep making new Itanium chips further reducing their overhead. As long as the cost reduction through stopping the chip business was less than the lost revenue from whatever businesses jumped ship it was a sound economic decision and based on the size and profitability of the enterprise group I'd say it was.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Yeah i think we had one of those at my first job at BHRA (based at CIT) cost the same as the small house about £250,000 in todays money
This looks a bit like a combination of dual-stack lite overlaid on IPv4 mapped IPv6. As you say, it needs IPv6 to even get off the ground
HP was like the last vendor standing. They even sued Oracle for stopping to support Itanium. Now they pull the plug themselves. Oh the irony.
WOW, you are very correct, it has been that long since I was in school that I had completely forgotten the absolute joy at getting a programmable calculator and putting away the slide rule. Dang I feel old now...
errr....umm...*whooosh* *whoosh* Is this thing on ?
or will they simply migrate HP/UX customers to Lintel (Linux on x64)?
One can only hope, HP-UX has been walking dead for years. 11.31 is six years old, 11.00 was released in 1997. It is at best an edge on an edge case, I want both the Itanium and HP-UX to go away. We have enough choice with Linux, Solaris, and AIX.
Compaq/HP should have left NonStop on MIPS and VAX on Alpha, and never gone the Itanic route w/ them
You're missing HP-UX on PA-RISC and Tru64 on Alpha. This is why HP jumped on the Itanium bandwagon. They weren't big enough to be viable developing one CPU for in-house use and they had two (PA-RISC and Alpha) that they needed for their own product lines. Killing one and migrating to the other would not have gone down well with their customers or engineers, and wouldn't have solved the problem that successful microprocessor development is all about volumes: it doesn't matter if you've got a chip for a niche architecture that's twice as fast as Intel's, because they'll sell well over a hundred times as many as you and so you won't be able to compete on performance per dollar. IBM only manages it by sharing a huge amount of their designs between mainframe, supercomputer, and embedded chips, and even then the POWER line struggles relative to the Xeon - it's competitive, but it's not a clear winner.
DEC paid Microsoft to port Windows to Alpha. If they'd also paid them to port Office and Visual Basic, and had given away free Alpha workstations to the top thousand Windows software development companies, then we'd probably all be using Alphas now. They missed the boat, and HP had to deal with the situation as they found it.
The problem was not that they decided to go with an outsourced architecture, it was that the one they picked was a clusterfuck from the start. The philosophy behind the CISC movement was to produce chips that were easy for assembly writers to program. The philosophy behind the RISC movement was to produce chips that were easy for compilers to target. The philosophy behind the VLIW movement was to produce chips that are easy to design, but hard to program for humans and compilers. It failed the first three times Intel tried it, yet they managed to convince HP that this time it would work really well.
A better strategy for HP might have been to follow Apple's example with the Apple-IBM-Motorola group, and set up a new consortium to make workstation and server CPUs. Sun and Fujitsu were already starting to run collaborate on designs. Between them and HP, they might have been able to produce one line of CPUs that would be easy to emulate SPARC, Alpha, and PA-RISC on and which could have kept the performance lead over Intel. By sharing the development costs between the three of them (maybe four, if Motorola had been interested), they'd have been able to push the unit costs down quite a bit.
I am TheRaven on Soylent News
THAT'S THE JOKE.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
By the time HP acquired Compaq, the latter had already abandoned the Alpha. Therefore, when HP acquired Compaq, they should have sold/spun off the VAX & Alpha lines to another company, so that they wouldn't be left w/ the responsibility of either Tandem or DEC. After all, HP bought Compaq for Compaq, not these 2.
I agree that a consortium might have been a good idea, but PA-RISC was purely an HP architecture. That's why I suggested elsewhere in this page that since they needed to outsource CPU development, they should have sold PA-RISC outright to Intel, and let Intel develop the marketing strategy around it. As it is, the PA-RISC was close to or matching Alpha benchmarks when it retired, so had Intel taken it over at that point, they'd have started w/ an existing user base - HP's, and then proliferated it, either by having Microsoft port NT to it, or going fully Linux/BSD and getting all the Linux & UNIX guys to back it.
On the VLIW history, it was HP who started it - acquiring 2 VLIW companies Multiflow & Cydrome - and sold the concept to Intel. While VLIW was easy to design @ a chip level, the actual cost savings over RISC were minimal, once it was found that the real estate savings on die was just something like 10% once one got rid of register renaming, speculative execution and so on. As it is, in Itanium, register renaming is back, so today, that CPU is more RISC than VLIW. Nonetheless, it now looks headed for the dustbin of CPU history.
The platform was declared a failure by many years ago. The reason it survived so long was HP had VMS and Tandem customers. And HP made it such that the Itanic was their only ship sailing on their routes. Those who could leave got off along the way, the rest keep on paying.
If you look at the old SPEC figures you can see that it was a few times faster in a few tasks (and slower in others). However I believe many of those tasks were "embarrassingly parallel". So instead of buying one Itanic box you could buy two or more x86 boxes for the same price and get about the same performance for that workload and have more flexibility (better performance for other tasks). And possibly not use that much more power either - the Itanic was quite power hungry too!
Issue was that at the time, there were other forces @ work. Apple, IBM & Motorola had formed the AIM consortium to push PowerPC, MIPS seemed to be making inroads w/ workstations, particularly since it supported NT as well, and Alpha too was topping the charts. In the meantime, HP saw that it wasn't cost effective to keep maintaining their own CPU, and hence this partnership w/ Intel.
It wasn't a bad idea - the bad idea was making VLIW the vehicle for a new architecture. To an extent, Transmeta demonstrated that VLIW could be a vehicle for architectures, if its instruction set was just a vehicle for a different one, such as x86. Itanium did a fine job running PA-RISC binaries, and in this department, actually outperformed PA-RISC. However, it was a bad idea for running x86, given the dependence on the compiler. In Transmeta's case, all that they did was code morphing, w/o trying to keep deep & filled pipelines: that way, they didn't have to struggle to make a perfect compiler the way Intel or HP did.
Once Merced bombed, HP/Intel may have done well by taking that chip, and going w/ the code morphing strategy - it may have worked better. But make no mistake - PA-RISC was economically unsustainable for HP, which is why they got into this partnership w/ Intel in the first place. Also, VLIW was HP's baby, not Intel's
Wonder - if HP stops building boxes using the Itanium, can't Oracle point out in their defense that they were sued for discontinuing support to a platform that HP itself is no longer supporting?