Slashdot Mirror
Compaq: Alpha is Better Than IA-64
Compaq released a document (it's in PDF format) that states that their Alpha is better then IA-64 (Intel next generation Itanium Processor). The document compares Alpha (and future generations of Alpha) against the IA-64 (I hate this "Itanium" name - where do they get these names anyway?). Certainly worth a read. What do you think, folks?
The alpha processors are not changing their niche in the computer market. They are ripping fast - and Dec first and now Compaq plays to the supercomputing crowd. The XP series motherboards and 21264 chips simply rip any other motherboard/chipset out there.
However, they cost too much for anyone except a supercomputing hound. If Compaq would drop Dec's insanely idiotic OS and component licensing scheme and aid linux on alphas, they might stand a chance of making a LOT of money selling hardware. As is, people buy ten times more alphas one chip generation late and run linux instead of OSF.
Anyone interested should see the linux alpha compilers available. cc is a small improvement, and ForTran is a LARGE improvement.
http://www.unix.digital.com/linux/software.htm
But still, Itanium will come out, and an Itanium box will offer slightly less than half the floating point speed, and it will cost about 1/4th of the fast alpha box from Compaq. And the alpha motherboards will still make it tough to support third party peripherals. And Itanium will dominate the 64 bit market. And Alpha will own the supercomputing market.
It's going to be tough for Digital to edge into Intel's market, mainly because nearly all consumers have been brainwashed to look for the "Intel Inside" Logo.
"Excuse me sir, is this an Itanium?"
"No, Ma'am. This is an Alpha processor by Digital corporation."
"Well Shit, I've never heard of THEM. Where are your Itanium machines?"
Not only that, but Alphas have never really been geared toward the general consumer. Most have been high-end server machines. Also, as far as I know, Alpha won't run x86 code because it uses a different architecture. (Please correct me if I'm wrong.)
"Alpha, huh?
"No Ma'am, this machine runs a Unix variant, and has a different architecture than Intel processors."
"Well Shit, I NEED those programs. Where are your Itanium machines?"
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
How do they come up with these processor names, you ask? An astute question, one that requires some of Intel and AMD's most closely-kept company secrets. A friend of mine who used to work for Intel managed to smuggle the following Perl script out, shortly before he was fired. Here it is:
./pnames.pl ./pnames.pl ./pnames.pl ./pnames.pl ./pnames.pl ./pnames-pl
#!/bin/perl
# Copyright (C) 1997 Intel Corporation
# This is a proprietary Intel perl script.
@prefix = ( "Pent", "It", "Max", "Ath", "Cort", "Trit" );
@suffix = ( "ium", "alon", "ex", "anium", "oricon", "agon",
"on", "eres", "obos", "ymede", "itan", "erion" );
@tag = ( "II", "III", "IV", "Pro", "MMX", "Deluxe" );
srand;
printf( "%s%s %s\n", $prefix[rand 6], $suffix[rand 12], $tag[rand 6] );
So if we run this script, we can see where the names come from:
sg1 237%
Cortium II
sg1 238%
Pentalon IV
sg1 239%
Penteres III
sg1 240%
Athalon Pro
sg1 241%
Pentitan II
sg1 242%
Maxymede MMX
Please show discretion when you refer this script to others. It is, after all, an Intel proprietary secret and should therefore only be shared with others on a "need-to-know" basis.
We're going down, in a spiral to the ground
Ok, I'll try.
:-)
Macin... Linux.
Ma... Linux
Linux.
Linux.
Nope, it just doesn't seem to come out.
(the irony is I'm posting this from a mac)
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
uh, it's gramm a r.
You can find inexpensive Alphas. www.dcginc.com sells complete Alpha systems for $1800-$5500 and bare bone systems for much less. Alphas CAN run 32 bit code under NT using the FX32! Emulator.
32 bit x86 code no less... Also, there is support for 32 bit x86 Linux binaries available (in Linux of course.) How well it actually works is best left for someone else to answer. I'm suprised that so many people thought there was no x86 emulation available.
Of course, the emulation isn't quite as important under Linux as it is under Windows since most software for Linux is open source and able to be compiled natively. Note that I am NOT implying that it's always as easy as simply recompiling the source...
BTW, doesn't seem like a great idea to go with an Alpha/NT combo these days anyway. Microsoft ceased development of NT5/Win2k/whatever for the Alpha. Presumably because they need to focus on rigging it to work with the IA64 first. I wonder if Windows for the IA64 will end up being enough 64 bit code to call it a 64 bit OS and as much of the old 32 bit code as they can get away running under emulation. Any guesses?
numb
This white paper is interesting, if non-objective. In my opinion, the authors are insufficiently careful to distinguish between irreducible architectural advantages and disadvantages and the (temporary) advandates and disadvantages resulting from current implementation decisions. They are also a little slippery about identifying which features are already present in Alpha implementations and which are not yet delivered (e.g. SMT).
The implementation of simultaneous multithreading is something I very much would like to see. I'm impressed that they're able to do it as simply as this paper seems to imply.
One Alpha advantage (one that I think falls in the irreducible category) that I've never seen Digital/Compaq play up is the angle of binary compatibility of the Alpha instruction stream across different implementaions of Alpha. A binary executable that the compiler has tuned/targeted to a specific implementation of Alpha will still run, perhaps not quite optimally, on a later implementation.
Out-of-order execution is key, here. Because the programmer (or compiler) have to be explicit (with memory barrier instructions) about dependencies that might otherwise be hidden, the instruction stream in the binary executable file documents an idealized instruction execution order -- but any execution order that achieves the same result is also acceptable.
More outstanding data fetches, larger out-of-order instruction queue and wider simultaneous issue all work together to transparently make the old code work better. I haven't seen where increasing the VLIW bundle from 3 instructions to 6 instructions, for instance, would be as transparent -- so there's a much stronger need to recompile and maintain separate binaries targeting the various implementations of IA64.
If you do a lot of very CPU intensive tasks, the alpha is quite a bit faster than a comparable x86 box. ...) is x86 only. If you need any of those, An alpha is not the right choice for you.
Other stuff (disk I/O, etc) is not faster than x86, and some hardware (e.g. many recent 3D graphics boards) can't be used in alphas.
Also, you should be aware of the fact that most closed-source Linux software (StarOffice, Netscape, Civ3,
This message is provided under the terms outlined at http://www.bero.org/terms.html
P6's can use various tricks to access more than 4GB, but only by using yucky segmentation techniques. At any one moment, only 4GB can be addressed because that's all 32 bits allow. You can't mmap in a 5GB file, or use an array of 550 million doubles. A 64-bit processor can access many petabytes-- directly. Not something useful on most app servers, but the database, video and science folks sure like it.
Following the suggestion, here are a few ports of the above program to some popular languages (substitute underscores for spaces when obvious):
:P
* Scheme
(let ((rand-elt
___________(lambda (l)
________________(list-ref l (round (rand (length l))))))
______(prefix '(Pent It Max Ath Cort Trit))
______(suffix '(ium alon ex anium oricon agon))
______(tag '(II III IV Pro MMX Deluxe)))
_____(begin
__________(display (rand-elt prefix))
__________(display (rand-elt suffix))
__________(display (rand-elt tag))
__________(newline)))
* Python
def rand_elt(list):
____list[int(rand(len(list)))]
prefix = ["Pent", "It", "Max", "Ath", "Cort", "Trit"]
suffix = ["ium", "alon", "ex", "anium" "oricon", "agon"]
tag = ["II", "III", "IV", "Pro", "MMX", "Deluxe"]
s = rand_elt(prefix) + ' ' + rand_elt(suffix) + ' ' + rand_elt(tag) + '\n'
print s
That's all for now... I seem to have run out of creativity
To the editors: your English is as bad as your Perl. Please go back to grade school.
MIPS does; however, POWER and Alpha may not. The first POWER and Alpha processors were superscalar (PowerPC being a descendant of POWER).
You're confusing (as per my followup to the person who responded to you) the support for 36-bit physical addresses in the P6 processors (PPro, PII, PIII) with the support for 48-bit segmented virtual addresses, which dates back to the 386 (and which is a 32-bit-segment-offset version of the 286's segmentation). You don't need to use 48-bit virtual addresses, in their full shining glory, to get more than 32 bits of physical address.
There's code in the 2.3 kernel from, if I remember correctly, Siemens, to do exactly that.
I don't know offhand whether any of the BSDs support it; I think either Solaris 2.6 or Solaris 7 do.
The segmentation tricks don't help much, if at all; the x86 MMU maps 48-bit segmented addresses to 32-bit linear addresses, and then maps 32-bit linear addresses to 32-bit physical addresses or, on P6, 36-bit physical addresses if that feature is being used by the OS. Thus, you can't get at more than 4GB of linear address space at any one time - you'd have to map segments into and out of the linear address space, although I guess you could do that on demand, so that it's somewhat transparent (although still potentially slow).
However, all that does is, as you note, prevent you from addressing more than 4GB at any one time; stuff can be mapped into or out of the address space (which I guess could be considered a "yucky segmentation technique" - you're an old-timer like me, so you may remember the use of that on some versions of PDP-11 UNIX and various PDP-11 OSes from Digital), and you can have more than one address space by having more than one process.
More than 4GB of physical memory is more useful on machines that let you get at it all at once, in a single address space, but it probably has some use even on platforms such as x86, SPARC V7/V8 with SPARC Reference MMU, etc. that have only 32-bit linear addresses but support more than 32 bits of physical address.
...in a single instruction. You can do 64-bit arithmetic on 32-bit platforms (for example, most if not all modern C compilers for 32-bit platforms support long long int or some equivalent 64-bit integral data type), but the operations generally have to be synthesized from multiple instructions (typically done inline for most operations, although multiplication and division, and possibly others, might be done in a subroutine), with each instruction working on 32 bits at a time, and may require more registers, as the non-floating-point registers on a 32-bit platform are typically 32 bits wide.