Slashdot Mirror
Alpha-Based Samsung Linux Goodness
Peter Dyck writes: "This summer Compaq divested itself of the Alpha technology. The Alpha tech was purchased by Intel who most likely will bury it after grafting its best aspects to their own 64 bit IA-64 system. However, the non-exclusive terms of the deal allowed Samsung
to continue producing and developing the best 64-bit processor architecture there is today. Now, as a happy owner of a four years old DEC AlphaPC164 I was delighted to see this announcement by Samsung Electronics. In short, the upcoming UP1500 motherboard will house a 64 bit 800+ MHz Alpha 21264B CPU, 4 GB DDR memory, 10/100 Mps LAN, USB and yes, it will run Linux."
The present CPU that is employed in Compaq machines like the AlphaServerSC and the Wildfire and in various cluster systems is the Alpha EV67 processor. The previous chip was shipped with a clock speed ranging from 666-833 Mhz. IIRC, the EV67 was able to deliver up to two floating-point results per clock cycle. The load/store units could load 16 B/cycle while the store bandwidth is slightly smaller: 10.6B/cycle. The bandwidth to memory is 5.3B/cycle, however, the type of memory determines the actual bandwidth through the bank cycle time of the memory. We were expecting a scaled up version of this chip named the EV68. It was projected to have an 833Mhz clock speed. I believe that this is perhaps some version of it.
The density used is 0.18 instead of 0.25 which enables the location of a 1.5 MB secondary cache on chip. The largest difference will be that there will be 4 dual channels from the chip to interconnect it with neighouring chips at a bandwidth of 1.6 GB/s per single channel for what Compaq has called "seamless SMP processing". The path to memory is implemented by 4x5 Rambus links as the systems will be fitted with Rambus memory. The direct I/O dual link from the chip also has a bandwidth of 1.6 GB/s. Theoretically the chip could run at speeds of upward 1Ghz.
I know that the Alpha 21264B is based loosely on the EV line of chips (more specifically the 67 and 68), can anybody further verify this with some more details? Thanks.
the byproduct of years of oppression by the white man
Most extended instruction sets (MMX,SSE,3dNow,Veocity) that work on large chunks of floating point data at a time are not designed for accuracy - they are designed for speed. In an environment where precision is required only IEEE floating point is of vale - the extended instructions are great for Quake, Photoshop and benchmarks, but hopefully nobody is using them for real work.
You assertion that X86 processors are 'brilliant engineering' is a but odd - X86 processors have a lot of cruft around to deal with old 8-Bit,16-Bit (Real and Protected) and 32-Bit modes. The Alpha and other chips that have been introduced in the last few years don't have all that garbage lying around and can concentrate on doing things correctly - where X86 designeres spend a lot of time making the things backwards compatible. Instead of being a 'Porche' as you described it - they end up being a VW Bug with a turbine engine graftwed on the hood - it works but it sure is ugly.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
You have to go to the link, and make sure to look at the large image near the bottom.
The image shows the 32bit pci bus only running at 33Mhz! I mean... I own a DIGITAL AlphaStation 4/233, and it has a 33Mhz. THis box is from 97.
Just guessing from what I saw on the page... the kit is a strange malgamation of old, and new technology. The system has 133Mhz, btw nothing new for Alpha, for the memory bus, but not the pci bus.
So... its is 64 bits.... but it isn't that special either.
It isn't a lie if you belive it.
Other Alpha systems are also not difficult to locate in eBay's Computer section. Just do a search on "alpha". The machines of interest aren't difficult to locate in the results, as there are rarely more than 4 pages' worth.
And the brethren went away edified.
Almost all modern apps require hacks like MMX and 3DNow? (Realize that while you're using either of those, you can't use the floating point pipeline because it uses some of the same paths as the SIMD engine. Also note that it costs cycles to switch back and forth and if you're not doing LOTS of matrix math, you're not going to use them- you're going to use hand tuned floating point/integer code.) How many really, really use them? Not a lot of them, in reality.
x86 has hacks to get SIMD instructions, limited register spaces, weaker floating point, etc. AltiVec is a more rational scheme and PPC CPUs have much more useful register sets and rational instruction sets, and it's floating point is nearly twice as fast.
Hacks do not a "Porche" make. To use your analogy completely, the x86 is a Mustang GT to the PPC's Porche. Both will get you there. Both go fast- but one is higher performance and handles better.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I feel like I'm feeding the troll here, but anyway...
Almost all modern apps require x-86 extensions such as MMX, SSE, and 3dNow,...
You'd only worry about this if you don't have access to your software's source. Besides, why should a non-x86 architecture support x86 features?
However, the Alpha, in keeping with the "pure RISC" philosophy, has MVI (Motion Video Instructions), which consists of a "whopping" 4 instructions (really).
Only certain flavors of Unix will run on an Alpha, while Almost all Unices, Windows, DOS, BSD, OS/2 etc. are supported by x86 based processors.
Could you please specify which "certain flavors" of Unix run on the Alpha? Where do you get the impression that x86 boxes are supported by "almost all Unices"? Last time I checked, I could not run IRIX, Tru64, or AIX on an x86 PC (there used to be an x86 version of AIX, but those days are long gone). Windows definitely did run on the Alpha (up to NT 4.0). FreeBSD, NetBSD, and OpenBSD also run on it. And bringing up DOS, OS/2, or OpenVMS is not worth the trouble, as they only run on a single platform (Yes, I know about OS/2 on PPC, but did anyone pay attention? NT/Alpha got a lot more usage than that).
In Soviet Russia, Jesus asks: "What Would You Do?"
An older board - the UP2000 - is a dual processor SDRAM (not DDR) based Alpha motherboard, which has 6 PCI slots, two of which are 64-bit.
This new board has DDR ram, but only 32-bit PCI, and then only three slots. While nice and all - DDR is good, and of course it's for the Alpha 21264B, not 21264A - this does seem a bit of a step backwards in the IO stakes. Especially when it's noted that the UP2000 has onboard Ultra-2 SCSI as well.
Perhaps this board was originally targetted at the 'lower-end' workstation segment? Does anyone know if a more server-oriented 21264B board is on the way? It seems sadly unlikely given the current circumstances.
If one wants to have 64-bit multiprocessing on a budget, what are the current alternatives?
I believe the comparison you are talking about is here: www.compaq.com/hpc/ref/ref_alpha_ia64.pdf
Better get it quick before it mysterisouly disappears like all other pro-Alpha/anti-IA64 material...
Bill
While there is no doubt that there is lot of cruft in the x86, you have to give Intel credit for getting way more performance out of it than anyone thought they wood. I remember back in the early 90s everyone kept talking about how RISC was going to kick Intel's ass for these very reasons: they would never be able to overcome the limitations of having to support backward compatibility. Yet, they are still standing, and RISC's advantages are very small in real terms.
You should probably doublecheck your sources, as they seem to have misinformed you on a couple of points.
Firstly, the past several generations _are_ RISC chips, with a wrapper around them that translates x86 instructions. This is why Intel chips have more decode stages in the pipeline than any clean architecture would (and why they were so eager to use a trace cache in the Itanium - among other things, it lets them skip the decode stages for instruction batches the processor has seen recently).
Secondly, there is a *huge* performance difference in practice between RISC and CISC architectures, for the simple reason that you can't pipeline CISC processors. You have instructions that do wildly varying amounts of work, taking wildly varying amounts of time to do it, sometimes without the total execution time being known (like the "loop" and "rep [foo]" instructions). Pipelining requires an instruction set with instructions that take roughly the same amount of time and that share many steps in common between instructions. RISC neatly provides all of this.
You can partially pipeline a CISC machine by only pipelining some types of instruction - heck, even a RISC machine will need to special-case things like divide operations - but pipelining is far, far more effective with a RISC architecture.
This was one more nail in the coffin of CISC cores (there are serious hardware and compiler complexity problems too).