My memory is that the Alpha and OSF/1 hit at the same time. OSF/1 had a different model of shared library stuff, and I recall it being something which sometimes demanded a reboot to get a runtime cache rebuilt/linked so things worked as you expected. I may be mis-remembering, I think DEC had coded some pull up smarts to optimise the lib -> indirect -> actual call path into the shortest path possible.
I also recall the syslog being absolutely FLOODED with "unaligned access at..." messages.
It was fast. It was very fast. If you knew how to make the compiler to the precompile, test run, introspect, recompile cycle, it would work out from some sample state the right choices (branch prediction ordering?) and make your fast code even faster.
Digital, HP, and IBM had the foresight to supply NCSA with Windows NT machines with their respective not-Intel chips in them to make sure that they had a web browser on their platforms. I got the honor of using the Alpha machine, and so it got the most QA by far. I recall spending an unnecessary amount of time not only staring at the heat sink but occasionally showing it to the new guy so they could confirm my astonishment.
Having the free hardware mostly worked, but there was a long time before all of the data alignment bugs got sorted out. It got to the point where my CS classes had progressed enough that I started looking for them myself. Literally the first development tasks I got paid to do was code reviewing for word alignment bugs on 64 bit code. It was a long goddamned time ago so it's pretty fuzzy but IIRC not all 3 processors had exactly the same restrictions for all data types. So if it worked on Alpha it usually worked on the other 2 but not 100%.
I didn't have to deal with 64 bit software at work again for another 10 years, at which point people looked at me like I was trying to be edgy when I just shrugged. No, really, I was looking at 64 bit code errors 10 years ago.
Most of the barriers for Alpha adoption were problems inherent in the 32-bit to 64-bit transition. Alignment problems, yes, but another killer problem was that 64-bit pointers were twice as large.
The software I was writing at the time (EDA) took almost exactly twice as much memory. So if we needed more than 4GB, we could go to a 64-bit machine, but unless you bought even more than 8GB, you couldn't really run on bigger problems.
As you note, all those problems had to be sorted out 10 years later, when AMD finally forced Intel's hand into selling 64-bit computers.
AMD only pressured Intel into adapting the 64-bit extensions to the x86 architecture, The Intel native 64-bit system was the Itanium. Which they were hoping would break x86 and it's messy open legacy that allowed AMD to profit off it.
A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the architecture fine) but I assume that x86-64 is intel face saving propaganda.
> A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the architecture fine) but I assume that x86-64 is intel face saving propaganda.
There exist two different (and slightly incompatible) implementations of 64-bit x86, which the respective CPU vendors call AMD64 and Intel 64 (previous names of the latter: EM64T and IA-32e).
So, what Intel implements is not AMD64, but something slightly different.
Concerning the small incompatibilities between AMD64 and Intel 64, see for example
If you go far back enough "x86-64" was the original unbranded name. I wrote to AMD back at the time and they sent me a 5-volume set of programmer's reference manuals labelled x86-64, dated 2002.
In those days, I was using SGI machines to build web sites for folks .. the Indy was very popular for this purpose. One day I was given a DEC Alpha machine to evaluate and see if it was a worthwhile addition to our inventory.
It came with NT, so there was some friction to just adding it to our services. These days were very frustrating - Microsoft was hell-bent on killing Unix, and later Linux also - and there was a lot of back and forth in our engineering team whether we wanted to invest in this hassle.
We didn't. I had that machine under my desk doing basically nothing for a year, before I sent it back.
If there had been a bit more insight into the nature of things, and if it had been running a Unix variant, we would have given it a better chance.
So then it was even more frustrating when SGI did a deal with the devil in later years, and tried to get its customers switch to NT, also. That killed SGI, in my opinion.
Looking back now, it's kind of incredible the resistance to Unix in those days, and how it was all going to be replaced with some "New Technology". Linux won. SGI didn't. And DEC was an early victim they should have learned from, in my opinion.
From Microsoft’s POV they soundly beat Unix in the 1990s because they were primarily focused on the GUI workstation market.
In 1991 the market for high-end desktop software like engineering, video editing and 3D modeling tools was dominated by Unix and classic Mac. In 1999 all of those applications were on Windows NT.
Vendors like Autodesk and Avid were building for Windows first. New graphics acceleration hardware targeted PC add-on cards rather than being exclusive to a workstation vendor (SGI tried this approach with their NT box and it flopped).
In retrospect it was just commercial Unix that had lost the game, but it wasn’t obvious at the time that Linux could reclaim this market. And Mac OS X was considered by many a doomed project (after all Apple had been promising a new OS for the entire ‘90s, nobody knew how deeply the NeXT acquisition would transform the company).
Between 1997 and 2007, I worked at 3 different companies, in 3 different countries (2 in Europe + Israel) as Design Engineer in electronics.
All the serious engineering programs for EDA/CAD were run on Solaris and accessed from Windows with X-terminal programs.
Towards the end of that decade, the Opteron-based servers were both much faster and much cheaper than the Sun servers or the Fujitsu servers, so the EDA/CAD programs were migrated from Solaris to Linux, while the Windows computers continued to run only the X-terminal programs for accessing the servers.
At the beginning of that decade, I also used a Sun workstation, but those disappeared after 1999, because they were much too slow in comparison with a PC with Intel Pentium III or with AMD Athlon.
It is likely that the reason why those EDA/CAD programs did not have Windows versions at that time was that they already required a lot of memory, typically much more than 4 GB, so they migrated from Solaris to Linux only after the availability of x86-64 servers, while having a Windows version was not possible before mid 2006, when Intel joined AMD in providing 64-bit CPUs even for PCs, not only for servers, so the market share of 64-bit PCs became non-negligible.
Yeah, even in like 1996/1997 for certain industries there were hints as to the way things were going, even if it took 4/5 years for the transition to fully take place.
For example, in 1996/1997, Digital Domain (VFX industry) used a 'render farm' cluster of Carrera Alpha workstations running NT to render the Titanic film, instead of SGIs running IRIX. (SGIs were still often used on the artists workstations though, but progressively that shifted).
By 2001, many of those machines were x86 which were then often as fast as the SGIs and Alphas, even with x86's stack-based floating point architecture which handicapped it a bit, and the significantly higher memory bandwidth and larger caches of the SGIs.
In 1999, AMD Athlon became the first x86 CPU that was able to do both an addition and a multiplication during one clock cycle, for the 80-bit x87 floating-point numbers.
The previous Intel CPUs of the P6 family, from Pentium Pro to Pentium III, required 2 clock cycles for that, i.e. they reached at most half the throughput of Athlon at the same clock frequency. And Athlon had an even higher clock frequency.
So the launch of Athlon was one of the greatest jumps in floating-point performance per socket in the history of x86 CPUs.
It had a higher clock frequency than any Alpha. IBM POWER CPUs could do much more per clock cycle than Athlon, but their clock frequency was much lower, so Athlon was still faster.
One year and a half later Intel launched Pentium 4, which could match the throughput per clock cycle of Athlon, but only when executing new SSE2 programs, not when executing any legacy program.
This was such a huge transition for FEM on x86-64. We went from UltraSPARC III 1.2GHz 24 CPU system with 128GB of RAM to a smaller Opteron two chassis cluster linked with Infiniband, 500GB 32core/8NUMA nodes per server, and the speedup was almost 10x.
> We rapidly concluded the DEC Alpha-based systems served our batch-processing needs very well. They provide extremely high floating-point performance in commodity packaging. We were able to identify certain floating-point-intensive applications as port targets. The Alpha systems could be configured with large amounts of memory and fast networking at extremely attractive price points. Overall, the DEC Alpha had the best price/performance match for our needs. [...]
> At this point, the decision was made to purchase 160 433MHz DEC Alpha systems from Carrera Computers of Newport Beach, California. Of those 160 machines, 105 of the machines are running Linux, the other 55 are running NT. The machines are connected with 100Mbps Ethernet to each other and to the rest of our facility. [...]
> The floating-point power of the DEC Alpha made jobs run about 3.5 times faster than on our old SGI systems.
The bit about how the AMD Athlon (K7) uses the same bus, and how they planned to make Slot A Alphas where the only adjustment an Althon motherboard would need is a different BIOS. Imagine what might have been, especially as Alpha Windows 2000 had a built in FX!32. Cheap Alpha systems with a good x86 compatibility story, it could've been a contender.
(Yeah, I know, several stars would've had to align for it to actually work).
Pretty cheap and pretty slow, relative to other Alphas. The various ATX-sized PC164s motherboards were the ones that should have sealed the deal for Digital, but intel had PPro at about the same time, with similar performance, less cost and probably most importantly ran all the software people already had and vendors didn't have to port to a new arch[1].
What might have been.
[1] Yes, yes...PPro sucks on 16-bit software. My personal experience was that was a red herring by the benchmark-jockies, because it wasn't that much slower, and virtually none of the many, many PPro machines I was responsible for ran DOS/Win3 software.
There was a second problem with that, Digital proved in court that Intel stole their architecture to put into the Pentium.
Part of the settlement was that Intel had to fab for Digital for a long time and pay for a bunch of their patents. The Digital folks made it sound like it was a victory for them but it felt like the beginning of the end, and sure enough it was.
I think Alpha's big problem was people were still migrating to 32 bit code and here was a bunch of smartasses trying to push 64 bit processors 10 years before x86-64 became the flagship for Intel-compatible processors. During the time when 'Internet time' was a thing people said regularly and unironically. 10 years was forever.
Sounds like similar paper "win" to DEC OpenVMS lawsuit against Microsoft where MS penalty was supporting Alpha while DEC trained its enormous sales/engineering arm to sell and support NT thus killing any incentives to buy DEC hw in the first place. DEC moved upstream the value chain and Microsoft moved tons of NT to all existing DEC corporate customers.
Some wise person in the 90's looked at the 16-32 bit transition, and side-eyed the 64 bit machines that were already available. He noted how differently we write software on 32 bit hardware (flat memory addressing, virtual memory, etc), and wondered what sorts of things we'd do differently on 64 bit. It took a while, but I think the answer is virtual machines, and multiplexing virtual addresses in a single process. There are some key techniques for highly concurrent garbage collection that use features meant for VMs to accelerate mark and sweep by switching the address space of objects that have been swept, and using some page faulting tricks to handle objects that are being written and swept at the same time.
We won't have to go to 128 bit processors for address space reasons. So I wonder what the justifications will be for doing so? And what features people will actually use it for when they have it? I suppose in some ways SIMD has skipped mostly over 128 to go to 256 and 512 bits though, hasn't it?
But I also know of 2 top-tier JITed languages that can use pointer packing to use 32 bit pointers for heap sizes under 32GB to save tons of memory. So 128 bit words would make pointers obnoxiously expensive.
According to the mighty google (and other HN comments) we are running out of address space at about 1 bit per year or so. So most of us will not live to see the need for 128 bit computers.
An interesting thing to think about is this: how extraordinary it was to live through 3 or 4 of these transitions. If we keep running out of bits at the rate of one per year (and we don't go extinct) that means that most humans will never life through any transitions.
We are either the lucky ones (because we got to seee so many transitions) or the unlucky ones (because we are the ones who had to cope with the disruptions of doubling pointer lengths.)
I seem to remember that Alpha’s were very fast for the time but their maximum optimization level waived IEEE floating point conformance. This, of course, drove us nuts trying to validate ports of numerically intensive code. Less interesting chips with lower optimization and limited market penetration.
Now, HP’s PA-RISC chips…. Those things were fast and easier to work with. Curiously, with SoftPC they could do windows faster than a 486 could. Slaughtered all sorts of mini-supers they did.
Would have been interesting if alpha survived to compete with SGI’s MIPS.
I worked on the first PA-RISC workstations (“snakes”, 1989-1991). PA-RISC started as a fairly pure RISC design and was consequently very simple and predictable (short pipeline, 1 delay slot, no complex instructions). The philosophy of the design team was to make the system fast with high clock speeds, short pipelines, and big caches, all big fundamental variables in the performance equation.
Alpha was much more sophisticated but also a lot more complex. The Alpha memory model, in particular, was quite complex with lots of cache control and barrier primitives, IIRC. But it could fly when you got the stars to align.
Edit: Alpha also came out later and PA-RISC also got more complex in later generations.
I feel like PA-RISC actually landed with a handful of useful somewhat-complex instructions. It always struck me as the best architecture from that era, making the correct trade-off of avoided microcode but adopted stuff like completers and shift-and-add operations to minimize instruction count and maximize work done per pipeline.
Yea, there were things like shift and add to do multiplication more efficiently, but they were all one-cycle instructions. It was very regular that way, all designed around a clean pipeline without a stalls or bypassing. But, consequently, it originally didn’t even have integer multiplication or division, just shift and add and a “divide step” that you could repeat/loop. Looking at the instruction set just now, I chuckled at how simple it was. It makes RISC-V look complex.
See: ftp.parisc-linux.org/docs/arch/pa11_acd.pdf
Edit: actually, it did have fixed point multiply via the floating point unit (opcode XMPYU). No fixed point divide, though.
what did they not implement from 754? Given the design of the processor i can imagine them being very aggressive with assumptions around exception handling / traps - iirc this is actually the original reason why Tomasulo algorithm exists because the first out-of-order processors didn't actually make any guarantees about the order that you would observe these side effects.
Alpha punts handling of denormals, infinities and NaNs to software emulation, but that wasn't particularly unusual: some sparc CPUs and early implementations of Arm VFP floating point did the same.
Looking at the alpha architecture manual, the fp emulation traps are imprecise, which imposes constraints on codegen to make it work right: the "trap shadow" extends from the potentially trapping insn until a following trap barrier, and in the shadow you mustn't e.g. use a register more than once as a destination, have a branch, or modify registers that are inputs to any insns in the shadow. (The idea is that the hardware will have already executed some of the insns in the shadow by the time it realises it needs to trap, and the handler has to be able to emulate the trapping insn and resume execution at the insn just after that, so it will re-execute all the insns in the shadow.) That's obviously pretty inconvenient for codegen, so I wouldn't be surprised if the compiler provided some kind of fast-math mode where it didn't trap and you just had to avoid generating denormals, infinities, etc.
I think making the fp using code have to be written carefully to work with the software emulation of edge cases is unusual -- I don't think either sparc or arm imposed that requirement, and instead trap precisely, or at least before anything happens where it would matter that the fp insn is emulated late.
It's important in the historical context of the Alpha AXP to also remember the DEC PRISM architecture. Canceled in 1988. One of many architectures killed off by DEC.
Without AMD rescuing x86, PowerPC wouldn't have died. MIPS wouldn't have died, and faces with the need to brake the 4Gn barrier on consumer equipment microsoft would have had windows running on three or four competing architectures until 2013 when everything would have switched to ARM.
It's unclear to me what would have likely happened had AMD stayed on IA32 and Netburst been uncontested. Itanium was far too expensive for consumer machines and it seems very possible that Intel would have fumbled IA64 in a way similar to more recent AVX-512 and their big.little efforts. Easy enough to port XP to Itanium, hard to get those machines into Best Buy or the Dell catalog in any way that makes sense. Had AMD continued Athlon performance improvements and Intel still responded with a P6-derived Pentium M (which even in our timeline was 32-bit) it still seems like there would have been no volume market for IA64 and we still would have eventually ended up with an evolution of IA32 even if it came from Intel instead of AMD.
First thank you for generously understanding my post despite the vandalism that autocorrect did to it.
WindowsNT is remarkably well suited to porting to other arch. This was done on purpose to hedge against x86. Dead one day, reactivated the other. MS needed to brake the 4Gb barrier and they would have done anything to get consumer priced 64bit chips.
Itanium was a dog. We had an Itanium SGI "supercomputer". Everything about it that SGI designed was amazing (hot swapping cpus). The cpu was a dog.
I heard about Alpha in that it while being more powerful than x86 it wasn't as alien as the competition. The boards had PCI slots and looked like normal PCs, it had Windows NT and Linux. So if your Exchange server was not handling the load you moved it to Alpha and it was good.
It also seems faith in IA64 was the meteor that killed most of these self developed RISC architectures.
A VAR I worked with back in the day made great scratch for a good number of years flogging MS SQLServer on Alpha for the performance boost, which was apparently more than enough to justify the price premium for those that needed it.
FWIW Alpha pretty quickly went with mainly PCI + few legacy ISA slots for considerable chunk of the line, unlike competition which used proprietary buses that might have been faster but meant extra level of exotic in procurement
> David Jessel, the Alpha's senior product manager, claims that Alpha fans have nothing to worry about. "Compaq has been fully supportive of the Alpha and is continuing to invest in it," Jessel said.
That worked out swimmingly for Alpha... >sigh<
I never programmed Alpha assembly, so I don't really have a feel for the architecture. I did deploy some Alpha-based boxes running NT, and they were very nice. They didn't feel pieced-together like x86 servers did.
On the hardware side, DEC built very-well engineered hardware. The early Alpha machines were very well designed. Even the PC compatible lines of the era were built to a very high quality standard.
'As DEC’s Corporate Vice President of PC Systems and Peripherals from 1990 to 1992 Grant successfully restarted DEC’s PC business from a dormant state and grew revenues to $350M and break-even profitability in 18 months.'
@18 minute timestamp - they copied DELL strategy and it worked, business was growing and then DEC founder and CEO Ken Olsen decided to kill it. Grant got recruited to lead Adaptec.
> Intel developed QPI at its Massachusetts Microprocessor Design Center (MMDC) by
> members of what had been the Alpha Development Group, which Intel had acquired
> from Compaq and HP and in turn originally came from Digital Equipment
> Corporation (DEC).[8] Its development had been reported as early as 2004
BYTE magazine has been gone for almost 30 years now. Fuck.
Dr Dobbs has been gone for 12, which is still a long time, but when I first read the intro my brain transposed the two and I had a proper freak out before I realized what I'd done.
For everyone who says that the Alpha was a technically-superior CPU design that should have prevailed, I will draw attention to an interesting fact:
"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 issue was not that Alpha ISA was impossible to scale down.
The issue was that DEC lacked the resources to run a completely new microarchitecture design to target low-power platforms, and the failure was trying to push an extreme performance chip into low-power envelope instead of designing a new one.
AFAIK with ARM the difference is that they started with low-power underpowered chip and modified it to bring the performance up.
You'd have probably similar issues trying to make a phone using Fujitsu A64FX (the supercomputer ARM) into low-power chip.
This interview with Allen Baum seems to imply that DEC was quite aware of what could easily be done with Alpha, and what could not.
I'm also assuming that ARM code density was better than Alpha (conditional opcodes being a major contributor).
"Well, we were looking at doing a low power Alpha and decided that just couldn’t be done, and then looked at the ARM. We think we can make an ARM which is really low power, really high performance, really tiny, and cheap, and we can do it in a year...
"Well, I worked on the StrongARM 1500, which was a very interesting product. It was an ARM and a DSP kind of highly combined... And then we finished that project and our group in Palo Alto, we were just gonna start an Alpha project."
An important thing to consider is that DEC simply didn't have enough CPU design teams, which is also why Alpha essentially had only one-and-half model in the works throughout its history - and the half came from smashing smallest chipset variant into single chip with the CPU for pretty bad performance (too slow memory, mainly). A low-power Alpha CPU would have to be a from scratch design, even if arguably simple to implement ISA-compatible chip.
StrongARM was developed in partnership with ARM, not starting from zero, applying some of the techniques Digital developed with Alpha to ARM - reputedly creating the idea that ARM could be fast at all
"Meanwhile, the engineering team's predictions about the relentless march of CMOS proved true. By 1991, the NVAX was also on the market, offering roughly the same performance for a tiny fraction of the cost and size. At lower performance settings the same design was available in desktop form, outperforming all previous VAX machines. The 9000 managed not only to lose billions of dollars, but also led to the ending of several much more promising designs."
Hardly anyone ran NT on these beautiful chips. Tru64 was the OS of choice for these in 1998. Hence the decision by MS to cease support. Running NT on a Dec Alpha would be like running kerosene in your Ferrari’s engine. If you wanted to run Windows NT you could do so a lot cheaper on an x86 PC.
Decision to cease support was reputedly done by Compaq, coming as complete surprise to both Compaq-side and Microsoft-side NT teams.
As for Alpha, funnily enough the first few years I knew of it, I knew only of NT use with them, because that's what the R&D institute my father worked at had.
My memory is that the Alpha and OSF/1 hit at the same time. OSF/1 had a different model of shared library stuff, and I recall it being something which sometimes demanded a reboot to get a runtime cache rebuilt/linked so things worked as you expected. I may be mis-remembering, I think DEC had coded some pull up smarts to optimise the lib -> indirect -> actual call path into the shortest path possible.
I also recall the syslog being absolutely FLOODED with "unaligned access at..." messages.
It was fast. It was very fast. If you knew how to make the compiler to the precompile, test run, introspect, recompile cycle, it would work out from some sample state the right choices (branch prediction ordering?) and make your fast code even faster.
Digital, HP, and IBM had the foresight to supply NCSA with Windows NT machines with their respective not-Intel chips in them to make sure that they had a web browser on their platforms. I got the honor of using the Alpha machine, and so it got the most QA by far. I recall spending an unnecessary amount of time not only staring at the heat sink but occasionally showing it to the new guy so they could confirm my astonishment.
Having the free hardware mostly worked, but there was a long time before all of the data alignment bugs got sorted out. It got to the point where my CS classes had progressed enough that I started looking for them myself. Literally the first development tasks I got paid to do was code reviewing for word alignment bugs on 64 bit code. It was a long goddamned time ago so it's pretty fuzzy but IIRC not all 3 processors had exactly the same restrictions for all data types. So if it worked on Alpha it usually worked on the other 2 but not 100%.
I didn't have to deal with 64 bit software at work again for another 10 years, at which point people looked at me like I was trying to be edgy when I just shrugged. No, really, I was looking at 64 bit code errors 10 years ago.
Most of the barriers for Alpha adoption were problems inherent in the 32-bit to 64-bit transition. Alignment problems, yes, but another killer problem was that 64-bit pointers were twice as large.
The software I was writing at the time (EDA) took almost exactly twice as much memory. So if we needed more than 4GB, we could go to a 64-bit machine, but unless you bought even more than 8GB, you couldn't really run on bigger problems.
As you note, all those problems had to be sorted out 10 years later, when AMD finally forced Intel's hand into selling 64-bit computers.
AMD only pressured Intel into adapting the 64-bit extensions to the x86 architecture, The Intel native 64-bit system was the Itanium. Which they were hoping would break x86 and it's messy open legacy that allowed AMD to profit off it.
A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the architecture fine) but I assume that x86-64 is intel face saving propaganda.
> A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the architecture fine) but I assume that x86-64 is intel face saving propaganda.
There exist two different (and slightly incompatible) implementations of 64-bit x86, which the respective CPU vendors call AMD64 and Intel 64 (previous names of the latter: EM64T and IA-32e).
So, what Intel implements is not AMD64, but something slightly different.
Concerning the small incompatibilities between AMD64 and Intel 64, see for example
> https://stackoverflow.com/questions/29833938/what-is-the-com...
If you go far back enough "x86-64" was the original unbranded name. I wrote to AMD back at the time and they sent me a 5-volume set of programmer's reference manuals labelled x86-64, dated 2002.
In those days, I was using SGI machines to build web sites for folks .. the Indy was very popular for this purpose. One day I was given a DEC Alpha machine to evaluate and see if it was a worthwhile addition to our inventory.
It came with NT, so there was some friction to just adding it to our services. These days were very frustrating - Microsoft was hell-bent on killing Unix, and later Linux also - and there was a lot of back and forth in our engineering team whether we wanted to invest in this hassle.
We didn't. I had that machine under my desk doing basically nothing for a year, before I sent it back.
If there had been a bit more insight into the nature of things, and if it had been running a Unix variant, we would have given it a better chance.
So then it was even more frustrating when SGI did a deal with the devil in later years, and tried to get its customers switch to NT, also. That killed SGI, in my opinion.
Looking back now, it's kind of incredible the resistance to Unix in those days, and how it was all going to be replaced with some "New Technology". Linux won. SGI didn't. And DEC was an early victim they should have learned from, in my opinion.
From Microsoft’s POV they soundly beat Unix in the 1990s because they were primarily focused on the GUI workstation market.
In 1991 the market for high-end desktop software like engineering, video editing and 3D modeling tools was dominated by Unix and classic Mac. In 1999 all of those applications were on Windows NT.
Vendors like Autodesk and Avid were building for Windows first. New graphics acceleration hardware targeted PC add-on cards rather than being exclusive to a workstation vendor (SGI tried this approach with their NT box and it flopped).
In retrospect it was just commercial Unix that had lost the game, but it wasn’t obvious at the time that Linux could reclaim this market. And Mac OS X was considered by many a doomed project (after all Apple had been promising a new OS for the entire ‘90s, nobody knew how deeply the NeXT acquisition would transform the company).
Engineering never went completely to Windows NT.
Between 1997 and 2007, I worked at 3 different companies, in 3 different countries (2 in Europe + Israel) as Design Engineer in electronics.
All the serious engineering programs for EDA/CAD were run on Solaris and accessed from Windows with X-terminal programs.
Towards the end of that decade, the Opteron-based servers were both much faster and much cheaper than the Sun servers or the Fujitsu servers, so the EDA/CAD programs were migrated from Solaris to Linux, while the Windows computers continued to run only the X-terminal programs for accessing the servers.
At the beginning of that decade, I also used a Sun workstation, but those disappeared after 1999, because they were much too slow in comparison with a PC with Intel Pentium III or with AMD Athlon.
It is likely that the reason why those EDA/CAD programs did not have Windows versions at that time was that they already required a lot of memory, typically much more than 4 GB, so they migrated from Solaris to Linux only after the availability of x86-64 servers, while having a Windows version was not possible before mid 2006, when Intel joined AMD in providing 64-bit CPUs even for PCs, not only for servers, so the market share of 64-bit PCs became non-negligible.
Fair enough, while the engineers used Microsoft things, the telecommunications industry - and many, many others - simply switched to Linux.
I know only a handful of hardware designers who use Linux/MacOS, and if they do, for sure there's a Windows VM or a spare machine in the cubical too.
Some sort of stasis has been accomplished.
Yeah, even in like 1996/1997 for certain industries there were hints as to the way things were going, even if it took 4/5 years for the transition to fully take place.
For example, in 1996/1997, Digital Domain (VFX industry) used a 'render farm' cluster of Carrera Alpha workstations running NT to render the Titanic film, instead of SGIs running IRIX. (SGIs were still often used on the artists workstations though, but progressively that shifted).
By 2001, many of those machines were x86 which were then often as fast as the SGIs and Alphas, even with x86's stack-based floating point architecture which handicapped it a bit, and the significantly higher memory bandwidth and larger caches of the SGIs.
In 1999, AMD Athlon became the first x86 CPU that was able to do both an addition and a multiplication during one clock cycle, for the 80-bit x87 floating-point numbers.
The previous Intel CPUs of the P6 family, from Pentium Pro to Pentium III, required 2 clock cycles for that, i.e. they reached at most half the throughput of Athlon at the same clock frequency. And Athlon had an even higher clock frequency.
So the launch of Athlon was one of the greatest jumps in floating-point performance per socket in the history of x86 CPUs.
It had a higher clock frequency than any Alpha. IBM POWER CPUs could do much more per clock cycle than Athlon, but their clock frequency was much lower, so Athlon was still faster.
One year and a half later Intel launched Pentium 4, which could match the throughput per clock cycle of Athlon, but only when executing new SSE2 programs, not when executing any legacy program.
This was such a huge transition for FEM on x86-64. We went from UltraSPARC III 1.2GHz 24 CPU system with 128GB of RAM to a smaller Opteron two chassis cluster linked with Infiniband, 500GB 32core/8NUMA nodes per server, and the speedup was almost 10x.
Regarding the "Titanic" film, from the Linux Journal (https://www.linuxjournal.com/article/2494):
> We rapidly concluded the DEC Alpha-based systems served our batch-processing needs very well. They provide extremely high floating-point performance in commodity packaging. We were able to identify certain floating-point-intensive applications as port targets. The Alpha systems could be configured with large amounts of memory and fast networking at extremely attractive price points. Overall, the DEC Alpha had the best price/performance match for our needs. [...]
> At this point, the decision was made to purchase 160 433MHz DEC Alpha systems from Carrera Computers of Newport Beach, California. Of those 160 machines, 105 of the machines are running Linux, the other 55 are running NT. The machines are connected with 100Mbps Ethernet to each other and to the rest of our facility. [...]
> The floating-point power of the DEC Alpha made jobs run about 3.5 times faster than on our old SGI systems.
I believe the original Toy Story was 'created' on SGIs, but the render farm was SPARC.
A video of an 1994 presentation put together for Hot Chips VI on the 21164: https://youtube.com/watch?v=OHupqMbLj1g
An April 1992 University Video Communications presentation on the Alpha architecture https://youtube.com/watch?v=klg1FtHADso and then from 38m 19s on the 21064 CPU https://youtube.com/watch?v=klg1FtHADso&t=2299s . From about 2m52s https://youtube.com/watch?v=klg1FtHADso&t=172s to 4m 43s Richard L. Sites gives the Alpha team’s predictions from 1992 for the next 12-25 of CPU development, which seem to have been fairly on the nail.
(Sites hasn’t been idle recently either! He’s responsible for the ultra-low-overhead KUTrace: https://news.ycombinator.com/item?id=40972099 )
The bit about how the AMD Athlon (K7) uses the same bus, and how they planned to make Slot A Alphas where the only adjustment an Althon motherboard would need is a different BIOS. Imagine what might have been, especially as Alpha Windows 2000 had a built in FX!32. Cheap Alpha systems with a good x86 compatibility story, it could've been a contender.
(Yeah, I know, several stars would've had to align for it to actually work).
"Cheap" and "Alpha" would have been hard to pull of simultaneously. But it would have been really cool.
The AXPpci 33 boards were pretty cheap at some point. I had one at the end of the 90s and I think it was 100-200 Dutch guilders.
Pretty cheap and pretty slow, relative to other Alphas. The various ATX-sized PC164s motherboards were the ones that should have sealed the deal for Digital, but intel had PPro at about the same time, with similar performance, less cost and probably most importantly ran all the software people already had and vendors didn't have to port to a new arch[1].
What might have been.
[1] Yes, yes...PPro sucks on 16-bit software. My personal experience was that was a red herring by the benchmark-jockies, because it wasn't that much slower, and virtually none of the many, many PPro machines I was responsible for ran DOS/Win3 software.
There was a problem with that idea, DEC engineers working for AMD made K7 too fast for Alpha to compete.
There was a second problem with that, Digital proved in court that Intel stole their architecture to put into the Pentium.
Part of the settlement was that Intel had to fab for Digital for a long time and pay for a bunch of their patents. The Digital folks made it sound like it was a victory for them but it felt like the beginning of the end, and sure enough it was.
I think Alpha's big problem was people were still migrating to 32 bit code and here was a bunch of smartasses trying to push 64 bit processors 10 years before x86-64 became the flagship for Intel-compatible processors. During the time when 'Internet time' was a thing people said regularly and unironically. 10 years was forever.
Sounds like similar paper "win" to DEC OpenVMS lawsuit against Microsoft where MS penalty was supporting Alpha while DEC trained its enormous sales/engineering arm to sell and support NT thus killing any incentives to buy DEC hw in the first place. DEC moved upstream the value chain and Microsoft moved tons of NT to all existing DEC corporate customers.
"I am old, and have lived through four ages of the west, (the 8, 16, 32, and 64-bit ages), and have seen many defeats, and many fruitless victories."
Some wise person in the 90's looked at the 16-32 bit transition, and side-eyed the 64 bit machines that were already available. He noted how differently we write software on 32 bit hardware (flat memory addressing, virtual memory, etc), and wondered what sorts of things we'd do differently on 64 bit. It took a while, but I think the answer is virtual machines, and multiplexing virtual addresses in a single process. There are some key techniques for highly concurrent garbage collection that use features meant for VMs to accelerate mark and sweep by switching the address space of objects that have been swept, and using some page faulting tricks to handle objects that are being written and swept at the same time.
We won't have to go to 128 bit processors for address space reasons. So I wonder what the justifications will be for doing so? And what features people will actually use it for when they have it? I suppose in some ways SIMD has skipped mostly over 128 to go to 256 and 512 bits though, hasn't it?
But I also know of 2 top-tier JITed languages that can use pointer packing to use 32 bit pointers for heap sizes under 32GB to save tons of memory. So 128 bit words would make pointers obnoxiously expensive.
John Mashey?
According to the mighty google (and other HN comments) we are running out of address space at about 1 bit per year or so. So most of us will not live to see the need for 128 bit computers. An interesting thing to think about is this: how extraordinary it was to live through 3 or 4 of these transitions. If we keep running out of bits at the rate of one per year (and we don't go extinct) that means that most humans will never life through any transitions. We are either the lucky ones (because we got to seee so many transitions) or the unlucky ones (because we are the ones who had to cope with the disruptions of doubling pointer lengths.)
I seem to remember that Alpha’s were very fast for the time but their maximum optimization level waived IEEE floating point conformance. This, of course, drove us nuts trying to validate ports of numerically intensive code. Less interesting chips with lower optimization and limited market penetration.
Now, HP’s PA-RISC chips…. Those things were fast and easier to work with. Curiously, with SoftPC they could do windows faster than a 486 could. Slaughtered all sorts of mini-supers they did.
Would have been interesting if alpha survived to compete with SGI’s MIPS.
I worked on the first PA-RISC workstations (“snakes”, 1989-1991). PA-RISC started as a fairly pure RISC design and was consequently very simple and predictable (short pipeline, 1 delay slot, no complex instructions). The philosophy of the design team was to make the system fast with high clock speeds, short pipelines, and big caches, all big fundamental variables in the performance equation.
Alpha was much more sophisticated but also a lot more complex. The Alpha memory model, in particular, was quite complex with lots of cache control and barrier primitives, IIRC. But it could fly when you got the stars to align.
Edit: Alpha also came out later and PA-RISC also got more complex in later generations.
I feel like PA-RISC actually landed with a handful of useful somewhat-complex instructions. It always struck me as the best architecture from that era, making the correct trade-off of avoided microcode but adopted stuff like completers and shift-and-add operations to minimize instruction count and maximize work done per pipeline.
Yea, there were things like shift and add to do multiplication more efficiently, but they were all one-cycle instructions. It was very regular that way, all designed around a clean pipeline without a stalls or bypassing. But, consequently, it originally didn’t even have integer multiplication or division, just shift and add and a “divide step” that you could repeat/loop. Looking at the instruction set just now, I chuckled at how simple it was. It makes RISC-V look complex.
See: ftp.parisc-linux.org/docs/arch/pa11_acd.pdf
Edit: actually, it did have fixed point multiply via the floating point unit (opcode XMPYU). No fixed point divide, though.
VAX compatibility was very important to DEC- the Alpha has hardware to handle the non-IEEE VAX floating point formats.
what did they not implement from 754? Given the design of the processor i can imagine them being very aggressive with assumptions around exception handling / traps - iirc this is actually the original reason why Tomasulo algorithm exists because the first out-of-order processors didn't actually make any guarantees about the order that you would observe these side effects.
Alpha punts handling of denormals, infinities and NaNs to software emulation, but that wasn't particularly unusual: some sparc CPUs and early implementations of Arm VFP floating point did the same.
Looking at the alpha architecture manual, the fp emulation traps are imprecise, which imposes constraints on codegen to make it work right: the "trap shadow" extends from the potentially trapping insn until a following trap barrier, and in the shadow you mustn't e.g. use a register more than once as a destination, have a branch, or modify registers that are inputs to any insns in the shadow. (The idea is that the hardware will have already executed some of the insns in the shadow by the time it realises it needs to trap, and the handler has to be able to emulate the trapping insn and resume execution at the insn just after that, so it will re-execute all the insns in the shadow.) That's obviously pretty inconvenient for codegen, so I wouldn't be surprised if the compiler provided some kind of fast-math mode where it didn't trap and you just had to avoid generating denormals, infinities, etc.
I think making the fp using code have to be written carefully to work with the software emulation of edge cases is unusual -- I don't think either sparc or arm imposed that requirement, and instead trap precisely, or at least before anything happens where it would matter that the fp insn is emulated late.
Thinking longer about Alpha's imprecise faults made me realize that signaling NaNs can be quite useful in such case
600Mhz Alphas existed when there was 195mhz MIPS
turns out there is more involved in performance than just clock rate
who knew? (everyone)
And the Alpha was faster
The last line of the parent post makes it sound as if the chips didn't exist at the same time.
It's important in the historical context of the Alpha AXP to also remember the DEC PRISM architecture. Canceled in 1988. One of many architectures killed off by DEC.
https://en.wikipedia.org/wiki/DEC_PRISM
Killing Prism sent David Cutler into the arms of Microsoft.
Another dead architecture was Jupiter: https://en.wikipedia.org/wiki/Jupiter_project
Killing Jupiter sent many of DEC's DECsystem-10 customers to IBM.
Years later, they both seem like bad decisions.
It’s so good to re-read Tom Halfhill’s articles. I wonder where he’s been in the past… checks notes… 30 years I haven’t seen his writings.
He was my favorite author at Byte.
His LinkedIn says he’s retired for six years now. I hope he’s enjoying retirement.
> outside of the highly specialized embedded-application market, RISC is in retreat
with hindsight it is funny to realize that RISCs come back would start from inside that highly specialized market in the form of ARM.
And just like the 90s, every major tech company is making their own RISC chip[1]! Apple Silicon, Tensor, Graviton, Axion, Cobalt, Grace....
[1] - Though not exactly since they're all ARM ISA at the foundation.
Man, I loved reading Tom’s articles in BYTE.
Fun fact - Linus first trip to the United States was related to Linux-on-Alpha port and sponsored by Digital Equipment Corporation.
The Alpha CPUs didn’t implement the div instruction and Linus’ assembly version was faster than DEC’s in some cases.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
From back when IA-64 (A.K.A. Itanium) was supposed to take Intel to the promised land.
Without AMD, maybe it would have.
No, it wouldn't have.
Without AMD rescuing x86, PowerPC wouldn't have died. MIPS wouldn't have died, and faces with the need to brake the 4Gn barrier on consumer equipment microsoft would have had windows running on three or four competing architectures until 2013 when everything would have switched to ARM.
Itanium would have already been a rotting corpse.
AMD rescued Intel from its own management.
Sure it would, Windows XP 64 bits was alreary on Itanium, and NT versions for PowerPC and MIPS were already dead by then.
It's unclear to me what would have likely happened had AMD stayed on IA32 and Netburst been uncontested. Itanium was far too expensive for consumer machines and it seems very possible that Intel would have fumbled IA64 in a way similar to more recent AVX-512 and their big.little efforts. Easy enough to port XP to Itanium, hard to get those machines into Best Buy or the Dell catalog in any way that makes sense. Had AMD continued Athlon performance improvements and Intel still responded with a P6-derived Pentium M (which even in our timeline was 32-bit) it still seems like there would have been no volume market for IA64 and we still would have eventually ended up with an evolution of IA32 even if it came from Intel instead of AMD.
First thank you for generously understanding my post despite the vandalism that autocorrect did to it.
WindowsNT is remarkably well suited to porting to other arch. This was done on purpose to hedge against x86. Dead one day, reactivated the other. MS needed to brake the 4Gb barrier and they would have done anything to get consumer priced 64bit chips.
Itanium was a dog. We had an Itanium SGI "supercomputer". Everything about it that SGI designed was amazing (hot swapping cpus). The cpu was a dog.
I heard about Alpha in that it while being more powerful than x86 it wasn't as alien as the competition. The boards had PCI slots and looked like normal PCs, it had Windows NT and Linux. So if your Exchange server was not handling the load you moved it to Alpha and it was good.
It also seems faith in IA64 was the meteor that killed most of these self developed RISC architectures.
A VAR I worked with back in the day made great scratch for a good number of years flogging MS SQLServer on Alpha for the performance boost, which was apparently more than enough to justify the price premium for those that needed it.
FWIW Alpha pretty quickly went with mainly PCI + few legacy ISA slots for considerable chunk of the line, unlike competition which used proprietary buses that might have been faster but meant extra level of exotic in procurement
> David Jessel, the Alpha's senior product manager, claims that Alpha fans have nothing to worry about. "Compaq has been fully supportive of the Alpha and is continuing to invest in it," Jessel said.
That worked out swimmingly for Alpha... >sigh<
I never programmed Alpha assembly, so I don't really have a feel for the architecture. I did deploy some Alpha-based boxes running NT, and they were very nice. They didn't feel pieced-together like x86 servers did.
On the hardware side, DEC built very-well engineered hardware. The early Alpha machines were very well designed. Even the PC compatible lines of the era were built to a very high quality standard.
> Even the PC compatible lines of the era were built to a very high quality standard.
DEC had a moment between 1990-92 when they did pretty good in PC market. Oral History of Grant Saviers, part 2 of 2 https://www.youtube.com/watch?v=Od830KDrLUU
Oral History of Grant Saviers part 1: http://archive.computerhistory.org/resources/access/text/201...
Oral History of Grant Saviers part 2: https://archive.computerhistory.org/resources/access/text/20...
'As DEC’s Corporate Vice President of PC Systems and Peripherals from 1990 to 1992 Grant successfully restarted DEC’s PC business from a dormant state and grew revenues to $350M and break-even profitability in 18 months.'
@18 minute timestamp - they copied DELL strategy and it worked, business was growing and then DEC founder and CEO Ken Olsen decided to kill it. Grant got recruited to lead Adaptec.
Another somewhat related error in strategy was trying to keep VAX alive for longer than it should have been, especially the ECL versions
My understanding is that after Compaq sold the Alpha IP to intel, and quite a lot of the DNA ended up in Nehalem and Sandy Bridge.
Not sure about that bit...
What is well known however, is that a bunch of Alpha engineers wound up at AMD, and a lot of that DNA went into the OG Athlon
QPI was Intel's answer to the competition AMD's Athlon / HyperTransport had created
The funny part is that arguably both HyperTransport and QPI descend from the interprocessor links designed for Alpha EV7
IIRC, the Sunway CPUs used in Chinese supercomputers have an Alpha-like design.
BYTE magazine has been gone for almost 30 years now. Fuck.
Dr Dobbs has been gone for 12, which is still a long time, but when I first read the intro my brain transposed the two and I had a proper freak out before I realized what I'd done.
I remember Byte folding, but I’d blanked that it was a full 28 years ago.
For everyone who says that the Alpha was a technically-superior CPU design that should have prevailed, I will draw attention to an interesting fact:
"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
While AArch64 has been in the top supercomputer, a phone running on Alpha was not.
For this scalability problem, it deserved to die.
The issue was not that Alpha ISA was impossible to scale down.
The issue was that DEC lacked the resources to run a completely new microarchitecture design to target low-power platforms, and the failure was trying to push an extreme performance chip into low-power envelope instead of designing a new one.
AFAIK with ARM the difference is that they started with low-power underpowered chip and modified it to bring the performance up.
You'd have probably similar issues trying to make a phone using Fujitsu A64FX (the supercomputer ARM) into low-power chip.
This interview with Allen Baum seems to imply that DEC was quite aware of what could easily be done with Alpha, and what could not.
I'm also assuming that ARM code density was better than Alpha (conditional opcodes being a major contributor).
"Well, we were looking at doing a low power Alpha and decided that just couldn’t be done, and then looked at the ARM. We think we can make an ARM which is really low power, really high performance, really tiny, and cheap, and we can do it in a year...
"Well, I worked on the StrongARM 1500, which was a very interesting product. It was an ARM and a DSP kind of highly combined... And then we finished that project and our group in Palo Alto, we were just gonna start an Alpha project."
https://archive.computerhistory.org/resources/access/text/20...
An important thing to consider is that DEC simply didn't have enough CPU design teams, which is also why Alpha essentially had only one-and-half model in the works throughout its history - and the half came from smashing smallest chipset variant into single chip with the CPU for pretty bad performance (too slow memory, mainly). A low-power Alpha CPU would have to be a from scratch design, even if arguably simple to implement ISA-compatible chip.
StrongARM was developed in partnership with ARM, not starting from zero, applying some of the techniques Digital developed with Alpha to ARM - reputedly creating the idea that ARM could be fast at all
DEC also blew a fortune on the ECL VAX.
"Meanwhile, the engineering team's predictions about the relentless march of CMOS proved true. By 1991, the NVAX was also on the market, offering roughly the same performance for a tiny fraction of the cost and size. At lower performance settings the same design was available in desktop form, outperforming all previous VAX machines. The 9000 managed not only to lose billions of dollars, but also led to the ending of several much more promising designs."
https://en.wikipedia.org/wiki/VAX_9000
DEC also lost Dave Cutler's team over PRISM, which was also a deep cut. Deeper than the ECL disaster? Debatable.
DEC had no hope in the ECL money furnace and the loss of the VMS architect.
Hardly anyone ran NT on these beautiful chips. Tru64 was the OS of choice for these in 1998. Hence the decision by MS to cease support. Running NT on a Dec Alpha would be like running kerosene in your Ferrari’s engine. If you wanted to run Windows NT you could do so a lot cheaper on an x86 PC.
Decision to cease support was reputedly done by Compaq, coming as complete surprise to both Compaq-side and Microsoft-side NT teams.
As for Alpha, funnily enough the first few years I knew of it, I knew only of NT use with them, because that's what the R&D institute my father worked at had.