I 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.
> 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.
When 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.
My 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.
DEC 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.
Looks 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.
If you want to get really obscure, someone has implemented a substantial amount of VMS commands and related userland stuff for classic AmigaOS! http://aminet.net/package/misc/emu/AmiVms
You got the first part right, but the second part is not correct. All IBM and Sun products, without exception, were inferior to DEC Alpha and OpenVMS at that time because all of the best wanted to work for DEC. DEC failed only due to the strategic mishandling of the company in a way not unlike what was happening in a less formal sense over at Apple. Dave Cutler broke from DEC and created Windows NT at Microsoft. A quarter million people would lose their jobs at IBM the during the market transition to Alpha-infused x86 Windows NT made possible by the killing of DEC and its quarter million employees. Sun survived a while longer because of its roll in the emerging Internet backbone, but it too died.
[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).
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.
> If it had instead spent that vast R&D budget on PRISM and MICA, it would have had what became NT to itself.
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?
> It’s not clear to me whether they would have gotten as much out of it as Microsoft did out of NT, though.
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!
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.
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.
The RISC projects began flying even back when the VAX 8000 was rolling out --in other words, the later VAXes were not seen as final solutions, but pretty much to keep revenue flowing from incredible demand while they were methodically engineering what would eventually be Alpha. The big internal debate at that time was whether to maintain software compatibility between VAX (which had finally shrunk onto the 78032 chips) and PRISM using hardware or software. Ultimately, the decision was made to break compatibility and build ISA binary translators into the operating system (renamed "Open"VMS).
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: 9000 --All of the non-Alpha VAXes from the 8000 onwards were to support cash flow during the planned transition to what would become Alpha. I should say that is a generalization as I'm totally certain some non-Alpha systems were still needed for solutions that utilized custom hardware or support.
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.
VMS was the superior operating system for an era that was rapidly coming to an end. I managed a VAX cluster for a bit in the mid-80s and VMS was really better than any of the Unixes for managing a time-shared system with lots of attached terminals. But that sort of system was already heading out the door - we had early Sun workstations already. What replaced it (powerful individual user workstations connected via ethernet) was much better served by a Unix OS than VMS.
I 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.
What 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.
> 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.
Sure. 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.
You are correct. In spite of the carve-up of the company, many designers ended up at AMD. I'm a bit fuzzy on the details and it is second hand information, but as I remember it:
* 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.
At my university one assistant professor bought an Alpha powered PC. Don’t remember the brand but it was COTS as much as possible other students murmured. An attempt to find the economies of scale.
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.
I'm surprised that nobody has mentioned that Intel bought the Alpha IP in 2001. I don't know, but I've heard that enabled Intel to greatly improve x86 performance.
> They couldn’t build a high-end market at the scales they needed to support continued development at Intel’s pace.
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.
My 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.
> 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.
When 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.
Fun 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.
Was that doing a primary/secondary model where the primary wrote a timestamp to the shared disk and if the secondary didn't see that after X seconds, it would take over?
Old versions of NT4 and 2000 supported SCSI disks in the cluster. We had one for a "high availability" file server from Compaq and always regretted it - I'm pretty sure a single box would have been more reliable. There was a cross-over LAN cable between the boxes and there were SCSI heartbeats (using persistent reservations IIRC) over the SCSI bus, but we would almost always have an issue with the SCSI drives deadlocking and the cluster failing BOTH nodes due to a fight over disk ownership. We replaced it with a netapp NAS eventually.
For the GNN mail system, that was built on a pair of DEC Alpha 2100s, that were both connected to a pair of drive arrays. We had inherited that from ANS, and they had inherited that from O'Reilly.
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?
Yeah, at the time, pretty much everyone in George's Internet Operations group loved it.
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.
"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."
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.
A lot of companies used to have in-house historians and they did a surprisingly good job in some cases. However, their efforts are always susceptible to a back room deal followed by some sort of public performance to attempt to make the public record look good.
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.
Companies are limited liability. FOR THE INVESTORS. What is interesting to me is that corporations currently pursue some means for having as short a lifetime of retention as legally allowed.
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).
As I understand it, the main driver behind retention is discovery. It’s simply that reducing the corpus that must be searched reduces the likelihood that something bad will be found. And even things which seem reasonable at the time can seem bad in retrospect.
No, George was the nicest and most unassuming guy you could ever imagine. He never treated anyone like that. And that was also his biggest problem -- that made it real easy for the vipers elsewhere in the company to backstab him, poison him, and then throw him under the rug.
I too worked at AOL back then, but on the AIM team. When we bought ICQ the presence side of ICQ ran on the largest machine Dec would sell you. The vertical scaling worked very well, tho. Also porting the host code to Digital Unix made it ready for 64 bit in general. We eventually ported it to the cheaper clusters of Sun then Linux hosts that normal AIM used.
We did have some Tandem hardware, but at that time Tandem couldn't really deliver on the SMP needs that we had, whereas Stratus could. I have heard at least three of the "core four" founders talk about how they had used Tandem at a previous job where they had worked together and got seriously burned by the vendor, and that's why they went with Stratus at what later became known as AOL.
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.
Thanks for the insight, when I was with DTV our HP/Tandem rep always made a big deal about their footprint in AOL in what would have been the same time era you were there (mid 90s) and how they "created the internet you know today" but they always sounded more like sales guy tall tales than anything else. We kept their footprint constrained to database caches (effectively) because our Superdome couldn't handle the dual workload of Siebel and lots of read requests from APIs, which was a role they excelled at for us.
Putting SQL engines right on the drive arrays was a pretty cool idea. That let you offload a lot of I/O to the lowest level hardware that you could. That was a real mainframe-class trick.
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.
These 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.
It 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
I 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.
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.
> 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.
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.
My 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).
It 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?
As 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.
Ah, 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…)
"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."
"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."
Alpha 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.
If 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.
In this context it is relevant. Nobody was programming anything in Python in 1992. The question is, how much of Alpha's apparent performance was real, and how much was due to the missing memory barriers causing programs to go faster and produce surprising (incorrect) results, interspersed with the odd mysterious crash?
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.
I don't think you're giving much credit to people who were programming multi-processor systems at that time. As @mhh_ points out, the vast majority weren't writing code that was multi-threaded at all. Of those who were, fewer still were writing the kind of code that was so tightly synchronized that these issues would even surface. OS engineers (such as myself) and others who did so were typically much closer to the hardware and aware that it was a rapidly evolving field, so they knew to watch out for these kinds of land mines. If you want to cite "surprising results" and "odd mysterious crashes" try making it more than conjecture by providing some data. I was there and such things didn't seem particularly more common on Alpha than elsewhere.
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.
Also given that Apple (and SPARC) chips have a means to vary the memory model at runtime, I think the way things would go if memory consistency was genuinely blocking Alpha's progress then they'd change it. It wouldn't be an easy thing to stomach but we have about ten billion flavours of X86 and Arm sub-ISAs floating around today
Still doesn't matter much. How many times have you actually cared about atomics, even ignoring that the most common case by miles is 0 contention - for productivity you just get it right once and reuse the code.
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.
I don't think weak memory models are inherently bad. It's a trade-off. Keep in mind it was conceived during the early days of SMP - there wasn't the industry preference for stronger models, which was largely a side-effect of x86 chips choosing that approach with SMP years later.
And everyone wanting to be able to claim top shelf Java support.
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.
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 1108 had simplistic memory protection and didn't have cache so there was no concerns around cache coherency. The 1100/80 which came 15 years later finally introduced a cache that was really just a buffer and, to my knowledge, had no coherency scheme largely because of the way the architecture of those systems worked.
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.
Yes, it had a weak memory model, which I had to deal with when I was working with a chip subsequently designed by some of the same people so I know its drawbacks better than most. But saying that means it wasn't better is a non sequitur unless your only standard is the strength of the memory model. The weak memory model is, in a way, a continuation of the RISC philosophy: drive up clock speed and IPC by moving complexity from hardware to software. Just like load and branch delays, or (spit) register windows. As time has gone by we've gotten better at hiding those things under a hardware front end, but at the time it was a good choice borne out by the massive success of machines - not just DEC's - based on that philosophy. Yes, it was a pain to deal with, but achieving top-tier performance has always been a pain one way or the other.
The Alpha was the first machine I saw with something approaching a modern heat sink. In that era the thing was ridiculous.
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.
For somebody who knows little about these topics, why was the memory model made the way it was? I assume it's so that the chip would be simpler / more RISCy, and faster?
Weaker => more freedom to reorder => issue loads sooner => higher IPC/perf.
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.
"Better" depends on your metric. It is obviously easier to make a wide OoO superscalar implementation based on the Alpha ISA, but the archaic 32-bit x86 probably had slightly better code density.
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.
I 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 :)
Memories 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.
In '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.
I 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).
95 comments
[ 3.2 ms ] story [ 168 ms ] threadI 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.
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:
https://tinyurl.com/thatf4ce
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.
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.
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.
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.
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
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.
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.
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."
https://en.wikipedia.org/wiki/OS_2200
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...