12 ms·
How much better was DEC Alpha than contemporaneous x86? (2020)
- johnklos 3y agoI think it's interesting to consider that Alpha was in some of the fastest supercomputers in the world around the time it was cancelled. Somehow, some people still believe that it was cancelled for technical reasons, and that the reasons weren't related to Intel wanting to push Itanic as hard as they could. 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.
- masklinn 3y ago> Somehow, some people still believe that it was cancelled for technical reasons, and that the reasons weren't related to Intel wanting to push Itanic as hard as they could. 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.
- panick21_ 3y agoWhen Alpha became really good, DEC the company was going down. Then DEC became Compaq and then Compaq was going down. Then it became Intel and Intel didnt care. 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.
- robk 3y agoI remember doing testing on Alpha for Windows NT 4.0 for my summer internship at DEC Littleton in like 1995 and was really surprised how fast it ran. Certainly faster than any other gui server I’d ever tried at the time.
- cbm-vic-20 3y agoLJO or LKG? Those big Alpha machines ran native NT apps really fast.
- jakedata 3y agoMy uncle worked on the Alpha team at DEC in Maynard, MA. After retiring he found a nice opportunity consulting for Compaq and later HP. He referred to it as being Compaqted and I think he was always saddened that the company he devoted his career to came to such an end.
- NoZebra120vClip 3y agoI just flashed on that Trash Compaqter scene in Star Wars: A New Hope.
- jschveibinz 3y agoDEC made excellent equipment and excellent software to go with it. Their FORTRAN compiler was the gold standard. But IBM and Sun were too much competition in the transition to personal workstations and UNIX. It just didn’t fit their business model of enterprise computing via mainframes and accessories. I still believe that VMS was the superior operating system. And their support was outstanding.
- midoridensha 3y ago>I still believe that VMS was the superior operating system. It would have been interesting if someone had built an open-source VMS-like OS instead of Linux.
- mepian 3y agoActually someone did that: https://github.com/rroart/freevms https://github.com/rroart/freevms
- midoridensha 3y agoLooks like abandonware, and like it never went very far. I'm thinking more like modern Linux: originally, it was just a simple kernel and userspace (using GNU), and interesting to play with if you didn't mind a simple Unix-like system that only had text mode and couldn't really do much. Then XFree86 was added, and lots of other stuff eventually, and now it's a completely modern system running modern software, usable for all modern computing activities on modern hardware. FreeVMS never got there it seems. I'm wondering what it would be like if it had.
- nerpderp82 3y agoI used Alphas running OSF/1 I believe and Windows NT. They both were amazingly fast compared to anything else at the time (PPro 200, Sun Sparc). It is sad that they couldn't have been spun out. Clean architecture, great performance.
- johnthescott 3y agoa well known client of mine runs tru64 servers. new servers obviously run linux but the tru64 boxes do well.
- twoodfin 3y agoWhat you mean by “contemporaneous” matters a lot here, as a few of the answers cover. 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.
- toast0 3y ago> By the time they adopted x86-64—reluctantly or otherwise—Alpha was neither performance nor economically competitive. 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.
- twoodfin 3y agoSure. My point was that Intel's embrace of x86-64 marked the final door closing on any rationale for choosing Alpha over x86. >4GB without magic tricks was important even then for large scale database and similar applications. 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.
- MrBuddyCasino 3y agoDidn't AMD use the Alpha bus protocol or am I mixing things up here?
- jl2718 3y agoMy first computer job was a high school internship at a small software company that was gifted an Alpha for testing, and it was just sort of sitting there in the lab next to where I worked doing basically nothing until it failed to boot into ghost, and I decided that I was going to rewrite the ghost bootloader (drive mirroring over the network). 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.
- nwallin 3y ago> 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. 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.
- bradknowles 3y agoWhen I was hired into AOL as the Sr. Internet Mail Adminstrator in 1995, much of their hardware was still on the Stratus mainframes. That was some seriously powerful hardware with an equally powerful but arcane mainframe OS, but it was limited to just 32 nodes -- and even getting to that took some real magic. So, everything was slowly moving off Stratus, and primarily to HP-UX systems. It was a long, slow death. 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.
- nikau 3y agoFun story from a place I worked which got one of the first alpha 4100 sold in our country - it was having intermittent crashes that we couldn't figure out. 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.
- quercusa 3y ago
- virtualritz 3y agoThese machines were beautiful. In my first company, a small CGI/video production firm, we had an SGI Indigo High Impact and two DEC Alphas, the rest was PCs. 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. [1] https://en.m.wikipedia.org/wiki/FX!32 https://en.m.wikipedia.org/wiki/FX!32
- unnah 3y agoIt was not quite decades in advance. Although a version of FX!32 was demoed in 1993, the first production version was released in 1996. Apple's Power Macintosh already included a 68k emulator in 1994, and by 1998 it featured just-in-time binary translation like FX!32: https://en.m.wikipedia.org/wiki/Mac_68k_emulator https://en.m.wikipedia.org/wiki/Mac_68k_emulator
- hinkley 3y agoI ended up with one of two Alphas donated by Digital to ensure our software ran on their hardware. I was trucking along with that box while coworkers were running Intel cpus twice as fast before I started noticing the deficiency. Ultimately I let it go to participate in late night multiplayer gaming, not because the machine was particularly wrong.
- vaxman 3y agohttps://www.wired.com/1997/10/intel-dec-settle-alpha-chip-dispute/ https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-di... 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.
- laurencerowe 3y ago> 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.
- foobiekr 3y agoMissing: how unbelievably bad Ultrix was. 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.
- mnw21cam 3y agoMy research group in 2004-ish bought a couple of DEC Tru64 Unix boxes on the basis of their fast CPUs and the high availability features. We discovered fairly quickly that the OS was pretty awful compared to the Linux we had on all our other machines, and in particular the JVM was seriously crippled (which was unfortunate given most of the stuff we were developing was in Java).
- systems_glitch 3y agoIt must be a later ULTRIX thing, I've ran it on VAXen and it's a pretty good BSD-enhanced *NIX there. Did you ever run the earlier (3.x, 4.x) ULTRIX releases?
- icedchai 3y agoAs far as I know, Alphas ran Digital Unix (also known as Tru64 and OSF/1), not Ultrix. I remember using Ultrix on older DEC machines (DECstations) and it was quite bad.
- PeterWhittaker 3y agoAh, yes, Digital UNIX, whose shells would conveniently clip command output to the terminal column width, even when invoked in a script. 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…)
- chasil 3y agoIt wasn't better. 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 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=96835 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.
- mhh__ 3y agoWho cares about the memory model being weak? Arm is really weak too.
- jeffbee 3y agoAlpha is extra-weak. As in, even with dozens of grizzled systems programmers at the table you will still not be able to reason about the observable result of any sequence of loads and stores. This is at least a developer productivity issue, and becomes a performance issue if you are inserting fences all over the place whether they are required or you just aren’t sure.
- wbl 3y agoOnly if you have racy accesses which you should not.
- jeffbee 3y agoIf you think it's that simple you are exactly the kind of developer who would never have succeeded in programming the DEC Alpha. On the Alpha, even dependent loads and stores can be reordered by the hardware and observed in any non-program order on other CPUs. So if CPU 1 sets X to 42 and takes the address of X, and CPU 2 dereferences X, it can observe any value of X, 42 or whatever, even if both CPUs used explicit memory fences with regards to the address of X. This was so hard to grok that the Linux kernel was broken on Alpha during the entire lifetime of the CPU, not fixed until January 2018. The Alpha is so weak and hard to use that half the C++11 explicit memory ordering stuff is only relevant to that CPU.
- alexnewman 3y agoI remember working for a large financial company before the big crisis. Half the infrastructure was unix on x86 and the other half that made most of the money was on VMS running on Alpha. We eventually went to the itanic architecture and got maybe 30% more memory and everything else was harder. VMS on Alpha was freaking amazing. Toolchain sucked, compilers sucked, the developer interface was really rough. Think non ssh protocol to console with non vt220 compatible terminal, with custom non xwindows gui protocol to run emacs. No code works cause filenames look like e0:[funkychicken]\goats\maker.txt;2 The ;2 on the end is the version. It also had a distributed lock manager , a geo decentralized file system which the equivalent of distributed inotify integrated into the decentralized lock manager. 20x the horse power over our x86 nodes, and they supported cluster operations across all 50 of the alphas. We ended up replacing the batch processing with like 200 nodes of Hadoop and hbase. It was never as stable, scalable or fast as vms. It was 100x cheaper though :)
- nologic01 3y agoMemories are fading but circa 2000 (EV6) it was maybe the fastest single-CPU workstation you could buy for number crunching. Anything faster would be firmly in HPC territory budget and complexity. 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.
- dekhn 3y agoIn '94-95, the alpha was miles beyond x86 in terms of processor. Even 2001, the alpha had some truly impressive features related to x86 but it mostly at the server integration level. By 2007, the writing was on the wall. 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.
- fmajid 3y agoI had a DECstation 3000/300L in 1992. Amazing machines, let down by DEC OSF/1, a very quirky UNIX built on top of the Mach microkernel (a little bit like NeXTstep). I still have the CPU board itself: https://majid.info/images/reddit/alpha.jpg https://majid.info/images/reddit/alpha.jpg as well as the Phillips #2 screwdriver that was included in the box...