How much better was DEC Alpha than contemporaneous x86? (2020)
retrocomputing.stackexchange.com
retrocomputing.stackexchange.com
Then the web team brought in DEC Alpha 4100 hardware, and that stuff just absolutely screamed. They were getting performance that many in the company simply couldn't believe. I ended up taking four 4100s, each with four DEC Alpha processors, and ran a copy of BIND-9 on each processor. I suddenly had the biggest and fastest nameserver cluster in the world. I did the benchmarks at the time to prove it. We never did give back that rack of DEC Alphas to the web farm guys.
That was around the time that certain leaders in AOL realized that the Internet Operations group under George Boyce was effectively taking over the entire company, and so of course that had to be stopped. George was given a title without portfolio, and all his people were scattered to the four winds of the company.
That's also around the time I started seeing the brick walls going up between the operations side of the house and the developers. Those would be the same walls made famous by some of the best known books on DevOps, including "The Phoenix Project" by Gene Kim. Every time I've met Gene at a conference, he and I reminisce and continue our years long discussions over our different experiences at AOL and the different decades when we worked there, and how we bookended that process.
I really liked working for George. It's a real shame what they did to him.
But boy howdy, was that DEC Alpha hardware fast.
DEC sent out a very senior engineer to investigate, he eventually discovered some shielding had somehow been bent behind where a bus slot was soldered and with thermal expansion would short against some of the pins causing errors.
Aside from that they were rock solid.
DEC also sold us a weird windows cluster using where 2 boxes connected to the same scsi array, it was not so solid.
There were 2 windows servers both plugged into the same scsi disk pack, and it used a couple of crossover cables I believe for the heartbeat.
I remember the unix guys were ribbing the windows guy a bit who confessed he regretted pushing for the cluster as it was so unreliable.
It was the typical windows experience of the time with a management console that just hung when doing operations.
Was that some witchcraft with a Y-shaped SCSI cable, perchance?
We ran exchange and some databases on it.
Global Network Navigator was the first nation-wide ISP in the US, and was a partnership between O'Reilly and AOL. But then it got too big for O'Reilly to run, and AOL wasn't ready to take it over, so we made ANS take it -- at the time, we had recently acquired ANS as our Tier-1 network provider, and they knew a lot more about DEC Alpha hardware than we did. But then it got too big for them to deal with, and AOL finally had to take it over. The mail system part was given to me and my co-worker. We learned a lot about DEC Alpha hardware from GNN, and we loved it.
That system worked great, up until the time that DEC sent out a Field Engineer to upgrade the firmware on the drive arrays. Then we got weird errors when we tried to come back up. So, we switched to the backup systems that were connected to the same drives. And it was also hosed. Fortunately, I had started taking user mailbox backups to our Auspex NFS file server that week, so we had backups. We soon realized that over 50% of the POP3/leave-on-server mailboxes will change radically over the span of an day. And some of our mailbox backups were over eighteen hours old. So, most of those backups were actually useless.
We did finally get back up and running by mounting the backup mailboxes via NFS, but we lost pretty much all user confidence in the system by that time.
The drive arrays had been set up to mirror at the lowest level, then stripe across the mirrors in hardware. We then striped again across those volumes in software, which was a high performance disk striping technique we called "plaiding". We ended up breaking each of the lowest level mirrors and sending the whole bunch to the guy who wrote the AdvFS filesystem for DEC, but he never got better than 80% recovery of the data, which meant that on average every fifth character was wrong. So, pretty much none of those recovered mailboxes were useful.
That was the death knell for GNN. If you can't trust the mail system, then what else can you trust?
We were all calling it AOL 2000, under the premise that this is basically what AOL would turn into once everything was moved off the Stratus mainframes.
I don't think any of us realized just how silly that idea was.
Was that just a scheduled upgrade to "stay current" or was he there to fix a specific problem?
So I'm no stranger to middle and upper management Machiavellianism and the costs it inflicts on the organization as a whole, but was that a case of a guy getting too big for his britches and starting to order around / dictate to other bigwigs with the "wrong title", a lack of experience in defending budgetary turf, or the classic tech guy solving problems while the business peers simply scheme?
On a sort of related note, it is kind of saddens me that the historical record of hierarchical organizational decisions aren't preserved / document well in critical areas. There's documents and records out there likely showing where global warming research was suppressed by oil companies, cancer research by tobacco companies, or whatever it is that Halliburton gets away with (apparently funneling aid to Russia currently, but that may be a partisan hit job).
There are usually well documented hierarchies of management and their ostensible areas of responsibility. There are records of decisions and results by the companies as a whole. There's never a kind of historical record showing X group of people in the company were part of the "graph" of decision making that resulted in it.
There's usually lots of fall guys and the like taking the sword for the uppers, but at least you can do some tracing.
Anyone that setup stuff like that would probably get suicided by the CIA, or worse, trumped up and sent to Supermax.
These days I can only think of a handful of companies that do that, usually the old industrial giants like IBM, GE, etc. And who knows at what level the historians are involved or if they have access to internal communications.
But if corporations keeping detailed decision records led to management being the recipient of liability rather than the corporation/profits (and therefore the actual owners of the corp) .... I'm surprised corporations don't actually track internal comms better.
Probably because tort law likes big fat corporations to be the target of class action lawsuits, rather than some far more limited pocket middle manager, and law has aligned to that abstraction (for the good of the lawyer profession).
And all of his staff, while they were at it.
IIRC, porting Linux to Alpha was credited for its 64-bit support, which made the AMD64 port much easier.
Tandem was finally allowed to come into the company later, but had a relatively small part to play.
At least, that's the way it was when I left in 1997. I can't speak for what happened after I left.
Sadly, Tandem didn't seem to be able to deliver much else for us.
Database-wise, AOL decided to go with Sybase as the official company-wide solution. Don't know whose palms got greased on that one, but I could have lived with Sybase if that was the only problem.
No, AOL then had to decide who was going to be their sole database hardware provider, and they selected SGI for that. Now, SGI had some great hardware at that time, but databases is not something they did well. And SGI was not a principal hardware platform for Sybase, so everything that was developed had to wait another six months or so to be ported from the main hardware platforms over to SGI. And that's assuming it got ported at all.
And that's what was chosen as the infrastructure for implementing the new version of the AOL mail system that lived outside of Stratus -- Sybase on SGI. I could have lived with a database-backed mailbox store for the entire service, but only if it wasn't done using the combined shitshow of Sybase on SGI.
I still run a dual 1 GHz AlphaServer DS25 in colo. Its performance is excellent, particularly when one considers that it's more than twenty years old. The build quality is better than any x86 server one can get today - the traces have a three dimensional look to them, the cables from the power supply look like they'd be good for attaching a starter to a car battery, expansion is incredible, and, of course, like all good servers, it has a whole machine system management that's 100% controllable over serial, as it should be.
Performance wise, it's faster at most things than a dual 1.5 GHz Sun Fire V245 which is several years newer with PCIe, DDR2 memory and so on. It's an impressive processor architecture, and I keep hoping someone brings it back to life in FPGA or via, perhaps, via something like the Chinese Sunway architecture.
The more prosaic reason is that Compaq didn't care about Alpha, they announced they were switching to Itanium before divesting themselves of the IP (selling it to Intel), then merging with HP which had originated Itanium.
While originally announced under Compaq just a few months after the DEC acquisition, EV7 ultimately released under HP.
Then the Alpha team went to AMD and kicked Intels ass.
Over the next couple years Intel spent billion in rebates and got into anti-trust lawsuits in lots of countries.
When it was introduced, it was faster clock for clock and clocked significantly higher than Intel’s best chips.
This gap didn’t last. This is the period when Intel started to really differentiate on fab technology and at the same time successfully modernized their x86 microarchitecture. By the time they adopted x86-64—reluctantly or otherwise—Alpha was neither performance nor economically competitive.
This was at root a business problem: They couldn’t build a high-end market at the scales they needed to support continued development at Intel’s pace. Intel had their consumer business to cover even major screwups like Itanium. DEC of the ‘90’s did not have that luxury.
AMD's first AMD64 processor launched April 2003, Intel's first launched June 2004. Compaq had sold the Alpha IP to Intel in 2001. Yes, there were new Alpha models released in 2003 and 2004, but I don't think there was heart in it; in 1999, Compaq and Microsoft canceled Windows 2000 for Alpha during the release candidate phase.
In short, it shouldn't be surprising that a 2004 Intel processor was faster and cheaper than a high performance system line that hadn't had much investment for five years.
Believe me, there were still true believers waiting for EV8 in 2004, despite the mounting evidence that Compaq wasn't at all interested in proving the world was wrong about Alpha.
* The Alpha bus architecture was used directly as the foundation of the Opteron and Athlon64 chips.
* The Alpha chipsets were used for Opteron/Athlon64 (eg: irongate family)
* A lot of the internals formed the foundation of Athlon64/Opteron, including the floating point system.
* A bunch more foundational work that I wasn't clear on was used. Alpha was far more closely related to Athlon64/Opteron than a lot of people realized.
I did the FreeBSD port to AMD64 and had a bunch of back-channel contacts with former co-workers who moved to AMD at the time. I had a steady stream of engineering samples, toys, documents and gossip. I still have a bunch of it around somewhere as souvenirs.
Aside: My favorite "secret" was REX32 mode. It was a special mode where the CPU allowed access to the 64 bit registers in a 32 bit OS, think 32 bit WindowsXP. It did not require the OS to be aware of this. Context switching of this extra state was bolted onto the side of fxsave/fxrstor in reserved areas at the time. This mostly intended to allow things like hot spots of nvidia drivers and libraries to secretly work in 64 bit mode on Windows XP. I was told that it made significant improvements to benchmarks. Officially it was just an engineering test feature. Sadly, it was removed - for a number of reasons.
With Alpha, AMD got most of the scientists and Intel got all the IP.
HyperTransport (and everything else copied from Alpha) was a cleanroom solution. Intel's Quickpath is closer to Alpha's tech (along with some claims that stuff like AVX came from upcoming Alpha SIMD designs).
Alpha EV8 was planned to be very wide (8-issue) design with SMT and a massive SIMD unit. It was supposed to launch in 2004. Intel's chips didn't get that wide until Haswell in 2013.
Unfortunately the video card had no driver ready. So it sat under a desk unused for years. Being an embarrassing mistake at first, then forgotten and eventually obsolete.
It's interesting how different things are today. If someone came along today with a new ground-up design for a CPU architecture + ISA, that was truly "better", all they would need to do is to show it to the cloud hardware vendors, and they'd likely get a billion dollars of runway shoved into their hands.
I admined a bunch of alpha systems and oh boy did two things stand out. The first was that ultrix was a just bad. Bad, bad, bad. Terrible performance, laggy, just everything bad about vendor Unix of the era. Windows NT on the same boxes flew by comparison.
The other thing that stood out was how unbelievably bad first generation alpha text performance was. This is mentioned in that page when someone notes the lack of instructions to deal with 8/16 but quantities. But the lack of byte operations was deleterious: it meant things like grep were just dog slow next to literally anything else.
That one took a while to puzzle out, had to set COLUMMS to a ridiculously high number when running on DEC.
(I was responsible for an install script that worked on pretty much all UNIXes of the time. The first few hundred or thousand lines were just figuring out which expcetional platform was in play and tweaking various parameters to get consistent results from sh, awk/gawk/nawk, ps, grep, etc. The good old days…)
In the mid 90's, I worked at an ISP where we had an Alpha / DEC Unix box for shell accounts. All the users hated it and demanded SunOS.
The Alphas ran Windows NT.
They were about twice as fast as the fastest PCs at the time when we rendered with PhotoRealistic RenderMan for Windows and Real3D on them.
FX!32 was a thing of beauty. [1] Basically Apple's Rosetta but decades earlier.
I still believe that VMS was the superior operating system. And their support was outstanding.
It would have been interesting if someone had built an open-source VMS-like OS instead of Linux.
In what concerns the kernel, userspace is another matter.
[I remember asking an MS exec what they would do about Linux and their view, apparently for too long, was that since you had to be a stud to use it, they were content to compete with a KISS-like UX. They didLose the entire server market to Nobody In Particular with that strategy.]
The only party able to make “personal Unix” economically viable tho was NeXT’s Apple and I believe we are witnessing the end of that era now as Apple moves everything to embedded (due to 3nm ARM chips fabricated by TSMC that descended from DEC’s StrongARM embedded processors, also included in the DEC settlement with Intel).
Rest In Peace Ken Olsen.
It is interesting that there are, in hindsight, a couple of specifically identifiable missteps.
DEC wasted about one billion dollars on trying to develop the VAX 9000 mainframe-class VAX, when it was already clear that RISC was the way forwards:
https://en.wikipedia.org/wiki/VAX_9000
Remarkably, it came back from this with the Alpha, which shows what it could have done.
If it had instead spent that vast R&D budget on PRISM and MICA, it would have had what became NT to itself.
https://en.wikipedia.org/wiki/DEC_PRISM
https://en.wikipedia.org/wiki/DEC_MICA
PRISM was cancelled; some of the tech was salvaged to make Alpha.
MICA was cancelled; the project lead quit, and took his core team to MS, where they rescued OS/2 3.0 and made it into Windows NT, which has strong resemblances to the planned DEC MICA.
It’s not clear to me whether they would have gotten as much out of it as Microsoft did out of NT, though. The marketing of NT4 (at least) reached down to fairly small server setups (even if wasn’t particularly popular on the workstation side—hardware requirements?), what with the BackOffice branding and everything, and Microsoft wouldn’t have blown you off if you just wanted to give them $5k for a few licenses. As I’m reading it, DEC’s mindset couldn’t really support this kind of strategy.
Also, nearly nobody programs against the NT API as opposed to the Win32 API and things built on top of it. I can’t tell what the intention of MICA was—keep the nice native API essentially private and only expose the VMS “personality” running on top of it, like Microsoft did, or something else?
Oh, absolutely agreed.
MS did very well and the core of NT is a superb product. But merely having a superb product is not enough.
It's hard to see how big and how influential DEC was today. Now, young techies assume that an 8-bit byte is a universal thing, that it's natural and obvious that computers just obviously use binary and that means word lengths that are powers of 2...
Whereas DEC sold vastly successful minicomputers with word lengths of 12, 18, 24 and 36 bits as well as 8-bit and 16-bit machines!
https://en.wikipedia.org/wiki/Programmed_Data_Processor
And those machines inspired the designs and the command lines of CP/M and MS-DOS, and as such, directly and profoundly influenced the PC industry. These were not niche machines, they were the mainstream that led to the standard OS that made Intel a success with the 8080, and that in turn led to the Zilog Z80 that spawned many multi-million-selling 1980s home computers... but it also led to the PC.
DEC OS/8 (and its big sibling TOPS-10) are what led to not only the CP/M and DOS command lines, but also things like 3-letter file extensions (after a dot). Every .TXT and .JPG and .HTM file exists because of the PDP-8.
https://liam-on-linux.livejournal.com/81341.html
And that was a 12-bit machine, not 8-bit, or 16-bit like the PDP-11, the machine that led to the 32-bit VAX, whose VMS is the direct ancestor of MICA and NT.
UNIX was developed for the PDP-7, an 18-bit machine.
The machines and their OSes are nearly forgotten now, and DEC is a footnote, but the weird thing is that both the CP/M–MS-DOS–OS/2–Windows–Windows NT family evolved from DEC OSes on DEC machines, but also the Unix family was designed and implemented by a 3rd party on DEC hardware, and then ported to different DEC hardware.
The two big rival lines of OSes today both can be traced back to the same company's products.
Unix and microcomputers are what killed DEC... It foolishly bet against them, it bet on big iron and tried to turn its most successful minicomputer into a mainframe.
But even despite that, and wasting a mind-blowing amount of money, it still came back and produced the first 64-bit RISC chip, and the first 64-bit Unix to run on it, and it got a native version of the industry-dominating OS which grew out of its own cancelled project. And that chip was also the target of the first ever port of Linux to something non-x86.
It was an incredible comeback. It's tragic that ultimately it wasn't enough.
What didKill DEC was the blue blood Board, which had FOMO due to the rise of Microsoft (which, at that time, was still running on the anemic 286/386/486 chips, but still killing it due to NetWare and NETBIOS) which was being led by "one of their own" (sort'a --the estranged son of Rockafeller's lawyer) after having gotten started with just $100K (a kiss goodbye gift after he had dropped out of college?) The little misstep with DEC's first generation of PCs, which were Ken's personal babies, caused him to lose the support of the "desperate" Board and, well, you saw what they did...and One Thing Lead to Another...until:
I wasn't talking about the VAX 8000, but the 9000. Not the same machine, or processor.
> What didKill DEC was the blue blood Board,
Your weird capitalisation here is confusing me. What is "the blue blood Board"?
> the anemic 286/386/486 chips
Hang on, what? That's a timspan from the 1980s to the 1990s, from sluggish 16-bits to competitive 32-bit 2nd gen chips that started to obliterate the competition. It's ludicrous to lump all those together.
> but still killing it due to NetWare and NETBIOS
Not sure what "killing it" means in this context.
Not sure why you'd glue Netware and NetBIOS together.
Not sure what you're saying at all, in fact.
> which was being led by "one of their own" (sort'a --the estranged son of Rockafeller's lawyer)
So many weird unclarified allusions! Who? What? Where?
Do you want to try again without being cryptic and hinting at things that are not really meaningful to anyone else?
RE: "weird capitalization" - "Board" was capitalized because I was referencing a specific board of directors. "Blue blood" was not capitalized because I was characterizing the members of said board. The relevance of making that characterization was to emphasize that those board members were under INTENSE pressure from their peers/ancestors/descendants to achieve at least the level of success that they were all observing coming from Redmond, especially the younger members of their dynasties. I think they were fine with a Pinto-driving living legend like Ken and his armada of actual geniuses (not Geniuses) until Redmond got going. Then FOMO didn't even begin to describe what they were experiencing as "some geeky guy" made hundreds of billions of dollars and became the wealthiest man on Earth, right under their noses. (They've ensured that can never happen again, but I get my account here Closed if I tell how they did it.)
RE: 286/386/486 was the end of the original Intel X86 line (without Alpha-infused technology). They were in various stages of being knocked off by Chinese companies like VIA. Microsoft was porting NT away from that ISA (onto MIPS). Pentium came out of left field and scaled like crazy. I'm not sure if/when it's fair to stop attributing Alpha technology to the success of X86.
RE: "killing it" --NT on even a Pentium III was no match for a VAXcluster. A network of NT boxes interconnected by "field technicians" into a LAN was. (A "field technician" of that era would have trouble interconnecting VAXes --but they had more than ample capability to setup NetWare and NETBIOS networks in the most unusual ways and places.) In this way, it can be said that WindowsNT (and the budget it gained from legacy NetWare installations) literally connected the VAX to death, not unlike what VAX had been doing to IBM mainframes (and their clones) for sometime.
> weird un-clarified Well, you are a good person because when you sense a lack of context, you don't instantly hit downvote (unlike most on Hacker News).
I suggest amplifying this with examples, citations and links, and sticking it in a blog post somewhere that people can comment on. OSnews springs to mind.
It seems to me that you know a lot of the history here that I don't, and I'm a journo working in this field and a former VAX sysadmin. This stuff is on the point of being lost to history now. It NEEDS to be recorded.
And you seem to be a good person to do it.
Don't leave it as a few hints in HN comments.
Even this response explains a little, but it's a tease: it has no citations, no links, no pointers, and no explanations of anything except my specific questions.
You really need to amplify this with 10x more background for a general audience.
But PLEASE do so. It needs to be recorded.
This.
Microsoft Windows NT and Wall Street were already embracing the successor to X86 (called MIPS) in anticipation of X86 hitting the same (CISC) architectural limits that DEC’s VAX had. Things did not look good for old Intel.
The allegation was that when DEC shopped Alpha to Intel (who had the most advanced fabs behind DEC) looking for a second source chip supplier, Intel took a while and came back with a No, but then their all-but-dead X86 architecture suddenly appeared in a new gen chip called Pentium with Alpha’s tech. You can guess the rest if you weren’t around yet.
[Commoditized PCs that ran the X86 version of Windows Server allowed Asian producers with near-slave labor to do to DEC what DEC had done, albeit with an entirely Western workforce, to mainframe manufacturers, to the point where Compaq was eventually able to buy what was left of once great DEC and put it to sleep —-along with any need for the MIPS version of Windows NT. Apple teamed up with IBM for a while with POWER PC, Sun flopped around with Thin Clients and Amiga/Atari murder-suicided, but there was no stopping Windows NT on Alpha-infused X86. Eventually, the ensuing economic chaos caused everyone to turn to free software everywhere they possibly could (as the theoretical communists like RMS lamented in their final vindication after so many decades in obscurity). When Apple got its second chance with the iPhone, the first thing it did was capture the manufacturing capacity in China to prevent a repeat of what had happened with the PC.]
Kind’a puts a new perspective on Intel needing to use TSMC as AMD began promoting 7nm x86 chips.
Footnote: The state of the art DEC chip fab (Hudson) that DEC made Intel buy was where DEC had taken the simple ARM architecture and put it on steroids (StrongARM) such that its eventual descendants live on today, even powering iPhone.
I don’t think there’s a direct lineage from StrongARM to Apple Silicon. The StrongARM IP ended up at Intel which marketed it as XScale for a while before abandoning it. Apple bought PA Semi, which was started by ex Alpha designers, to design their CPUs.
Observe:
"According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible."
https://en.wikipedia.org/wiki/StrongARM
"The Alpha AXP has a notoriously weak memory model. When a processor writes to memory, the result becomes visible to other processors eventually, but there are very few constraints beyond that."
https://devblogs.microsoft.com/oldnewthing/20170817-00/?p=96...
No question, it could not compete.
Edit: $40,000 for a license for OSF/1|Digital UNIX|Tru64 was the real kiss of death.
The Alpha is so weak and hard to use that half the C++11 explicit memory ordering stuff is only relevant to that CPU.
The only SPEC (or SPEC-like) benchmarks I tend to pay attention to are single-threaded, multi-process (i.e. compile times) - Unless these bugs were in te kernel I'd imagine most unix-y workflows would be unaffected.
Years later, as I said somewhere in this thread, I worked with another (MIPS-based) chip designed by some of the Alpha engineers, with the same predilection for weak memory ordering. In about two years, I found three bugs related to missing memory barriers - one in NFS, one in NBD, and one in Lustre (which isn't even part of the kernel). Yes, they were a pain to debug. Part of the reason is that they would occur so damn rarely. Damn near 100% of the time the "vulnerable" code would run just fine anyway. Writing reproducers was a serious challenge. More importantly, these bugs were dwarfed by bugs of many other more familiar types - use after free, deadlock, protocol errors, etc. Any bugginess attributable to the weak memory model was noise.
So yeah, Alpha's performance was very real. Using hypotheticals to bash it in pseudo-retrospect seems uncharitable, to say the least.
Especially for the time, most code has been and is painfully single threaded, only really relenting quite recently.
Having an extremely strong memory model is also potentially a performance issue because the CPU is much more expensive for the same performance.
Say what you will about Java, but a lot of OSes and hardware had to get a lot better at multithreading pretty quickly or be relegated. Even Solaris struggled for a time.
This is vastly incorrect.
UNIX was ported to the Univac architecture in the late '70s. It ran as a client on EXEC 8, and was the first SMP implementation.
"The UNIVAC 1108 computer was announced in 1964 and delivered in late 1965. The first 1108 computers used Exec I and Exec II, which had been developed for the UNIVAC 1107. However, UNIVAC planned to offer symmetric multiprocessor versions of the 1108 with up to 4 processors and the earlier operating systems (really basic monitor programs) weren't designed for that, even though they supported limited multiprogramming."
The Alpha team was working on a much more sophisticated system and had to solve a much coherency problem. Weaker models allow greater throughput and save transistors (and reduce power/heat) at the expense of more carefully written software and operating systems.
It was the next generation of Intel and AMD hardware where users started learning about heat sinks. Things like you could fry your CPU in under a second if you accidentally turned it on with no heat sink.
Really that simple. You can get some of this with speculation and later checking, but that has its own costs and limitation.
People feel _very_ strongly about these topics. RISC-V eventually compromised and allows both TSO (~ x86) and a weak model (~ Arm). As far as I know, all commercial silicon supports the weak model and I suspect they only support that.
I'd love to know the assumptions behind the claim that a low-power Alpha couldn't be made. Maybe it was as simple as comparing a 32-bit CPU with 16 registers to a 64-bit CPU with 32 registers (4X the leakage for RF alone and > 2X the data path cost). Aarch64 is a bigger ISA than Alpha so I guess we crossed that bridge.
Come to think of it, had the cryptomining and LLM crazes occured a bit earlier it would have helped such architectures survive the onslaught of x86 excel pushing brigades. But it may have never led to Linux adoption. Sigh. Figuring out alternate tech universes is so complicated.
Even by 2007 we struggled to replace a mature TruCluster with 8 large nodes with a linux cluster; IO performance and cluster capabilities were still pretty lackluster.
After about 2008 I don't think Alpha was a viable alternative to anything.
I still have the CPU board itself:
https://majid.info/images/reddit/alpha.jpg
as well as the Phillips #2 screwdriver that was included in the box...
Well… this was obviously extremely naive and I did not succeed, but, I did a lot of reading through the instruction set manuals on that machine. The most remarkable feature I think was just the number of registers. IIRC there were 64 64-bit registers. I had done some x86 32 assembly, and I hated always having to push onto the stack because all they had was eax ebx ecx. It wasn’t until MMX that you could use more than that on x86, and there weren’t many. I wrote most programs entirely in registers, almost like LLVM today.
Well it wasn't that bad.
The Alpha had 31 integer registers and 31 floating point registers. (it had a 32nd register that would read a zero and writes were dropped) The 386 had 6 integers registers and 8 floating point registers. But if you squinted at it right, it also had 2 special purpose registers that the Alpha need to use its general purpose registers for: ebp and esp. (base pointer and stack pointer)
If you only needed 8 bit values, eax-edx could split its low 16 bits into two 8 bit registers, ie, you could use al and ah (bits 0-7 and 8-15 of eax) as registers, whereas in Alpha, a register is just a register.
Because of the CISC/RISC thing, lots of stuff that would need an extra register or two on Alpha could be done without using an extra register on x86. For instance, code that looks like array[i] = x, where the pointer for array is in rdi, i is in ecx, and x is in eax, on x86 you can just do `mov [edi + 4*ecx],eax`. On alpha this might be something like `s4add $4, $5, $6; stor [$4],$1;`. (my Alpha is...a little rusty. I can't remember if the output is on the left or right.) Alpha needs to spend a register ($4 in this case) to hold the computation of the address you're writing to, while on x86 the address you're writing to lives in a virtual register that isn't part of the ISA.
The Alpha didn't have sugary call/ret instructions that handled return values for you. On x86 call/ret implicitly push/pop the return address to/from the stack; on Alpha you needed to pass the return address as a register.
> It wasn’t until MMX that you could use more than that on x86
MMX didn't add any registers. It just turned the 8 80 bit floating point registers on the x87 into 8 64 bit special purpose SIMD integer registers, which are more or less powerful than the 6 general purpose integer registers depending on which way you're squinting at them.