Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Alpha 21264 CPU: NT's Greatest RISC (1998)

halfhill.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#71

Post by p_l »

rasz wrote: post #48
cbm-vic-20 wrote: post #14

Earlier quoted context omitted.

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.or…

Another somewhat related error in strategy was trying to keep VAX alive for longer than it should have been, especially the ECL versions

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#72

Post by kjs3 »

microtonal wrote: post #46
krylon wrote: post #26

Earlier quoted context omitted.

"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.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#73

Post by kjs3 »

hinkley wrote: post #40
rhelz wrote: post #39

Earlier quoted context omitted.

"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. T…

John Mashey?

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#74

Post by kjs3 »

irusensei wrote: post #52

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.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#75

Post by chasil »

p_l wrote: post #69
chasil wrote: post #64

Earlier quoted context omitted.

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, real…

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 i…

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.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#77

Post by hakfoo »

somat wrote: post #53
rhelz wrote: post #41

Earlier quoted context omitted.

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 big…

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 arch…

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.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#78

Post by ggm »

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.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#79

Post by stmw »

synack wrote: post #67
stmw wrote: post #18

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...

That's nice. (Not uncommon in early RISC, (e.g. PowerPC had some similar limitations for 64 bit ints), and various assembly fun ensued).

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#80

Post by pjmlp »

hedgehog wrote: post #49
pjmlp wrote: post #34

Earlier quoted context omitted.

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 AM…

It is all what ifs by now, however I firmly believe if there was no other option other than Wintel, Intel would keep pushing Itanium and sort out the design issues.

The thing with AMD64 is that now there is this myth that there was no other alternative than keeping up with x86, and Itanium redesigns for some magical reason were impossible.

Other than those redesigns never happened, because AMD64 made economic invalid to pursue them.

Post reply on HN