Hacker News Reader

Alpha cancellation happened before HP/Compaq merger, when it was purely Compaq decision.

At the time some partnerships were slowly reducing the base costs of making Alpha machines (with K7 Athlon motherboards and EV6 Alpha being essentially signal compatible but not pinout compatible - you could reuse the chips and most of the design).

Compaq however... was not interested, for various reasons.

Oh you must be right, I mix up my time lines.

In any case the economics were more or less the same as Alpha as for the others. They couldn't support integrated silicon manufacturing. It wasn't even just the manufacturing (which could be outsourced although arguably not as competitively as integrated shops like Intel until TSMC really hit its stride). Or the logic and physical design. But the software development and ecosystem support costs were ballooning too. Alpha like the rest of them just never made sense unless they could make competitive cheap systems that were compatible, and by the time efforts like Windows ports and x86 emulation came along, it was already too late.

I think you're right overall that Itanium is used too often as the reason why all the RISC platforms died/were cancelled, as if they would have had healthy futures had Itanium simply not existed, but I do wonder about Alpha.

I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms, Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.

It's not enough to suggest that it had a chance "in any reality", but it seems like a much more potent competitor than PowerPC or SPARC or MIPS, it only because of the platform and OS support. Both Windows and Linux had pretty capable x86 emulation software layers too, and not just at the very end!

> I think you're right overall that Itanium is used too often as the reason why all the RISC platforms died/were cancelled, as if they would have had healthy futures had Itanium simply not existed, but I do wonder about Alpha.

Alpha had no fundamental differences that would have enabled it to avoid the same problem as the others IMO.

> I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms,

No that's not true, other RISCs had similar, even before Alpha was on the designboard. They all did RISC workstations, Sun, SGI, even HP and IBM. IBM most famously went into PowerPC with Apple and Motorola early on, and then also did CPUs for several games consoles.

IBM probably of all of them understood the commoditization fight and they tried to put up a fight, but even they couldn't keep ahead of it. Alpha couldn't have.

> Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.

Just too expensive to produce for what it did. Why would you use it for a Windows or Linux machine if you could do the same with a Pentium or K6 that actually ran your games and word processors and other stuff.

Windows on Alpha and FX!32 were reasonably solid options, as was the general health of the Alpha ecosystem. The platform also was not overextended in dot-com boom as much as let's say Sun. Windows port was also pretty early, even if it was 32bit limited.

The big benefit for EV6 was that it had actual parts commonality with PC, and I do not mean few I/O chips like some of the others (SuperIO, network, etc.) but northbridge - anyone making a K7 motherboard could make an Alpha motherboard, and Samsung became first vendor selling both CPUs and complete systems with non-Compaq chips.

FX!32 was not good. DEC's own paper only provided results for "Byte Benchmark" (nbench) which is a few trivial compute kernels. Even that most favorable test they could find showed 500MHz 21164A performed about the same as a Pentium Pro 200, the core that would the next year be in consumer CPUs. It was also NT only, at the time not used for PCs. It's just not enough to be "as good" in a scenario like that where not only are you are massively disadvantaged by costs, but you have to break into existing markets.

EV7 and EV8 development did not go well either, costs and complexity was blowing out, EV7 slipped 18 months and planned 130nm shrink was not able to hit performance targets. EV8 was enormous and expensive totally unsuited to mass market commodity bottoms-up path of Intel, and exemplifies their retreat into high end niche rather than accept and embrace commoditization.

AMD licensed the EV6 bus, but of course there was no socket/pin compatibility between AMD and Alpha parts. So they still didn't have commodity motherboards, though that would only be one small part of the puzzle if they did have.

FX!32 was good compared to what was available elsewhere (including for Itanium IIRC). I am not saying it had to compete with fully with x86 on consumer desktops from beginning, but it would have been more stable position, especially with known upcoming work on 64bit-clean NT5.

EV7 I am interested in more details because I want to know if the slippage was part of the original development run, or the post-Itanium one when it was restarted by HP. EV8 was admittedly dead in the water but I would say not so much for technical reasons as much as for direction options available (vs. following the samsung partnership to bring more AlphaPC-like systems)

The motherboard difference was slight between K7 and EV6 parts from my understanding if there was a will to commit to large scale production (arguably EV67 could be probably made into pin-compatible packaging even). But admittedly small part.

> FX!32 was good compared to what was available elsewhere (including for Itanium IIRC). I am not saying it had to compete with fully with x86 on consumer desktops from beginning, but it would have been more stable position, especially with known upcoming work on 64bit-clean NT5.

I meant not good compared with what was available elsewhere, i.e., actual x86 CPUs. It didn't emulate privileged modes, so none of your operating systems worked, it required Windows NT, and it only provided emulation for Win32 x86 binaries, and it did not emulate all facilities either. Independent benchmarks are not easy to come by, but even the few results published by DEC were not fantastic. A 500MHz Alpha (likely EV6) would achieve maybe little better performance than a 200MHz Pentium (P5, not PPro)! EV6 did 2.66x specint95/MHz that Pentium MMX 200 achived, and 2.5x the frequency. Natively it would havehave been 5.32x faster on those benchmarks, but it was a little over 1.x. This is not the 40-60% performance claimed of the trivial byte benchmark result, this is 20% performance at best.

https://www.researchgate.net/publication/3214997_FX32_a_prof...

The slip was the original development AFAIK. HP later restarted a failed process shrink I think, but I can't remember if they finally got that done in the end.

> The vertically integrated RISC/UNIX minicomputer companies were not on economically viable trajectories.

Well, actually one survived, and is making a fruity company quite happy, which also survived the 16 and 8 bit vertically integrated home computer companies.

The successful merge of NeXT and Apple, meant PC OEMs now dream of margins of those days hence why building desktops has become a niche market, everything is vertically integrated across laptops, tablets and phones and smart devices.

That alternative timeline means Intel would actually bother creating 64-bit x86 server chips instead of Itanium, because on their roadmap they were never expecting AMD to come out with an alternative.

Yes NeXT/Apple survive, although they commodity m68k CPUs, not quite your traditional UNIX minicomputer. Those were IBM, Sun, HP, DEC, maybe SGI. Designed their own ISAs, CPUs, interconnect fabric, 3 of them did their own silicon manufacturing.

One does still survive though, that's IBM's POWER / AIX. Still actively developed, though there is the feeling of 'when' rather than 'if' for them too.

I did not count AIX / Solaris in, because they are always some racks in a server room, or the whole IBM / Unisys / Fujitsu for that matter.

I was only thinking about UNIX workstations, those under/besides the desk.

Otherwise you're right, there are few more options available still.

Not true, they all did workstations.

https://en.wikipedia.org/wiki/SPARCstation

https://en.wikipedia.org/wiki/IBM_RS/6000

https://www.reddit.com/r/vintagecomputing/comments/1fz29tx/r...

https://en.wikipedia.org/wiki/SGI_IRIS#MIPS

https://www.openpa.net/systems/hp-9000_720_730_750.html

Apple (or NeXT) were never vertically integrated back then. In the last 6 years with Apple making their own CPUs for OSX you could call them a vertically integrated UNIX shop. Not minicomputer though, which is from my post you replied to. Apple was not a vertically integrated vendor that survived bottom-up attack, they attacked Intel from bottom up via mobile/smartphone cores in a similar way Intel did to the minicomputers.

> If Itanium never happened, 64-bit x86 server chips would have done the same thing to MIPS, Alpha, PA-RISC, SPARC, PowerPC.

If AMD had launched amd64 server chips those vendors onboard we might have had a different 64-bit x86 market. And those vendors would have had a chance to succeed or fail on their own merits instead of due to dead end chip.

AMD did launch amd64 server chips. The first ones were Opteron, first (and only until Nehalem) x86 with ODMC, glueless multiprocessor up to 8-way (though that was a bit flakey, 4-way was decent), and first dual core. It destroyed Intel's CPUs in many measure of performance for server workloads.

Before Intel's decade of humiliation with their 10nm fiasco and before Zen, AMD had a hell of a time getting ISVs and IHVs on board in the server space with producing them, certifying them, etc.,. Which wasn't entirely irrational, Intel was much more mature in a lot of ways in their hardware and software stacks, they were a big company, perceived as less risky, etc.

So it's not too surprising that those companies didn't jump to Opteron. Some did consider it, mind you. Though AMD went through doldrums of their own after Opteron (with Core2/Nehalem-ish era) where they shat the bed with their cores and were pretty handily beaten by Intel for quite a long while until Zen came along -- so that is possibly some vindication for the risk adverse by not going all in on Opteron.

Yep, those vendors could conceivably been onboard and using launching on Opteron (if there was no Itanium and Intel was seen as the common enemy). They might have given AMD some help with the validation, RAS etc too.

Of course in the alternative history Intel might have done something else in place of IA64 that competed with amd64...

Already at launch, and also during the next few years, until Intel fought back with Core 2 (but in servers the Core 2 descendants became better than Opterons only in 2009, with the Nehalem Xeons), Opteron was immensely better than the UltraSPARC CPUs used in the Sun servers. Only the Fujitsu SPARC CPUs were somewhat competitive, even if still significantly weaker. The Intel Pentium 4 Xeons were also worse, despite higher clock frequencies.

But as you say, the inertia in servers is huge, so Opteron gained market share very slowly, despite being by far the most performant server CPU that was available.

Where I worked at that time, we had big server farms with Sun or Fujitsu servers, which were disliked by design engineers like myself for their slowness. We had to make great efforts to convince the management to buy a few Opteron-based servers. Of course, after we got them they ran circles around the Sun or Fujitsu servers, a single dual-socket Opteron could be much faster than an 8-socket Sun server whose cost was many times greater.

At a previous job circa 2008-12, we were a sun shop and moved from spark to x86 Solaris. It screamed at sustained, high-concurrency loads and our workloads benefited from the trinity of Solaris' threading, ZFS tiered storage, and zones/containers. By the time the Intel Nehalem chips became available to use, our DB loads screamed, too. There were edge cases where the sparc chips were better, but not at the price points offered. Linux was competitive at a performance level (though we always saw some issues if the machines were pegged for sustained amounts of time), but production containerization in those days was VMWare, which was enough of a performance hit to not be worth it.