Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Compaq

Compaq: Alpha is Better Than IA-64 373

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?
This discussion has been archived. No new comments can be posted.

Compaq: Alpha is better then IA-64

Comments Filter:
  • alpha has been 64-bit for a while ... Itanium only now .. Hello Unix vs Microsoft ..
  • Alpha: tru64 or Linux. As much as I love *NIX, eliminating themselves from most of the market share, they can have the best chip ever imagined, but Intel will still whip their butts. Can we say Macintosh?!?!
  • I think the real advantage is when operating systems become 64 bit, windows probably own't be for a long while, but is linux going to be 64 bit when it is ready on x86 architectures?
  • by Anonymous Coward
    Unfortunately it doesn't matter. The sheep will keep buying Wintel PCs. In this industry "good enough" has always been, well, good enough.
  • Just goes to show what bad marketing can do. Tell the average Joe about the Alpha and he's like "Alpha what?" And, yeah, I want one too. :)
  • I am not an expert in CPUs and I haven't read a basic CPU architecture schematic since the original Pentium came out. Therefore I cannot judge the merits of this document.

    I would like to point out that this document is from Compaq, so we must suspect that the document was written with a Pro-Alpha slant to begin with. Its like Intel coming out with a paper debating the merits of the Pentium III vs. the Athlon Processor.

    Manung
  • IIRC, there was an announcement a while ago that Linux was already running on the IA-64 engineering prototypes. Some companies (VA-Linux and others, IIRC), had gotten in with the whole NDA thing and done the work.

    Soon we'll have another 64 bit platform! For ultra-stud-muffins only. :-)
  • My understanding is that Linux IS 64 bits, as it runs on 64 bit alphas. It should be a pretty simple hack to modify it when it comes time to run on a 64 bit x86 processor.

    Finkployd

  • by blakestah ( 91866 ) <blakestah@gmail.com> on Tuesday December 28, 1999 @04:05AM (#1439749) Homepage
    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.
  • Everything I've read so far, even withstanding Compaq's propaganda, indicates that the Alpha will be
    faster
    cheaper
    *and* more powerful than Merced.
    Not to mention that the Alpha, anyways, is proven technology.
  • Duh.. WinNT runs on the alpha. (IIRC)
  • The PDF format is hardly Compaq's. If anything, it's Adobe's. Plus, the poster confused "than" with "then", /again/. :P
  • by Accipiter ( 8228 ) on Tuesday December 28, 1999 @04:09AM (#1439754)
    Intel is going to win. Why? No, not necessarily because they have a superior product (They obviously don't) but they have the marketing muscle.

    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? ..... Well, will it run Quicken, or Microsoft Money?"
    "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?

  • The best feature of the Alpha is that they are available. Or are they?

    I've wanted an Alpha for a while now because (for various geeky reasons: fun, supposed speed, fun, assembly programming, and fun) but I've never been able to find a reasonably priced machine (even for auction) OR good instructions on how to build them.

    If Compaq were smart (note the use of a counterfactual conditional) they'd hype Linux on Alpha like all get out. What better way to screw MS than to give geeks hardware that Windows can't touch (anymore)?

    But does Compaq want to screw MS? If they're smart they do: Compaq produces an ostensibly competing OS.
    ---
  • I'm no OS expert, but as best I can figure your largest gains in using 64bits as your native word size in an os come from two things.

    One is the ability to address more than 4GB of physical ram (which 32bit addressing is limited to). Linux already does this on alpha's.

    The ability to seek more than 4GB into a file (ie: fseek takes a 64bit offset, not a 32bit one). I'm pretty sure alpha linux has this too.

    I'm not sure what areas (if any at all) that alpha linux is 32bit where it should be 64, but I've been led to belive it is a full 64bit os (with exceptions of things that *have* to be done in smaller word sizes, like ipv4 addresses.. which must be 32 bit).
  • The coolest thing about the paper is the details, such as they are, about the EV8. It's essentially four CPUs slammed together on the same chip talking to one another, and if the OS supports it you get four separate threads running at once.

    This has the potential, along with a big cache, to really boost the performance of a box, as well as drop the price per bang down. SMP circuitry's not cheap or simple, and definitely non-trivial to design. But with the EV8, it's all been done for you...
  • As to Alpha's running x86 code, thats true. However, DEC has some software ( I think its called FX-32, or something ) that do some weird "not quite emulation" things. Which allow it under WinNT to run Win32 apps.

    I could be wrong. Its happened before.
  • So Alpha is fast and well designed and beats the shit out of x86 and IA64... What else is new? It's also irrelevant to a large majority of computing enthusiasts because the systems are really really expensive relative to the x86 boxes we can all go out and buy at Comp-U-Planet.

    I know a lot of people who would absolutely adore having an Alpha box, but they're just so expensive... We have a variety of free high-quality OSes working on Alpha and we've got millions of people who are now re/entering the land of *nix. Put 1 and 1 together and you get a large potential market for low-end, moderate-cost alpha boxes... My question is, where can we find them and what's holding up the market from bringing them to us at a sane price? Are we not looking hard enough or are they not there?
  • truly, is s/w being written because the OS is popular, or is the OS popular because the s/w is being written?
  • I'm also not an OS (or arch) expert, BUT I think another advantage is data bus (and register) size. You've already mentioned the address bus with your 4GB physical RAM, but you've neglected to mention that you can get (and use) a full 64 bit word from that address with a 64 bit OS.
    ---
  • Compaq is many things, maybe too many: that's why their management has turned over so much in the last year and their stock price has suffered. On one front, they compete with Intel. On another, they compete with Microsoft. And on yet another (and probably their most lucrative / profitable) they are partners with both. Which one will win? Whichever one consumers vote for with their money.
  • Alphas certainly deserve the market for high-end 64bit PCs, as it is a proven architecture that has been around since 1991 (or so). Even though the Merced is brand new, Intel will market it enough to dominate. I bet the Merced will be even more expensive than the Alpha! (Secret hope: there will be some hideous bug in Merced - like the original P5 and Chipzilla will fall flat on its face!)
  • To begin with, this is only the first version of the Itanium line of chips. For all we know, by the time the chip ships in SOHO computers, things will change. Also, the IA64 has one major advantage over the Alpha, the IA64 can run 32 bit programs (albeit at a considerable performance hit). For the first few years of the new chips, 32 bit software is what allot of people will use, so most computer manufacturers will only sell the IA64... Look, I am not anti-alpha, nor anti anyone else, I like competition, it lowers prices, but a realist must take all such releases with a grain of salt (Compaq is pushing its AMD line over its Intel line of machines, maybe they are trying to help AMD out, who knows). Either way, I look forward to owning a 64 bit computer someday.
  • 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.)


    You're right. You can run WinNT on Alpha's if you get a special Alpha-only copy of WinNT. But then you still need Alpha-only copies of everything else... For the most part this doesn't happen with Linux, FreeBSD etc. as everything is availailable in source form.

  • by cje ( 33931 ) on Tuesday December 28, 1999 @04:15AM (#1439770) Homepage
    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:

    #!/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% ./pnames.pl
    Cortium II
    sg1 238% ./pnames.pl
    Pentalon IV
    sg1 239% ./pnames.pl
    Penteres III
    sg1 240% ./pnames.pl
    Athalon Pro
    sg1 241% ./pnames.pl
    Pentitan II
    sg1 242% ./pnames-pl
    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.
  • http://www.dcginc.com used to sell resonably priced alpha hardware - it's been a while since I last looked though.

    Most places that carry alpha's are proberly willing to sell you a bare boned system, just board, cpu and box, and you should be able to build a system pretty cheap.
  • Duh.. WinNT runs on the alpha. (IIRC)

    Not anymore. Check this [theregister.co.uk] out.

    -Brent
  • If you're going to slam someone's grammar, try using 'its' for *it is*, rather than the possessive 'it's', which denotes something *belonging to it*. The original article said nothing about the PDF format belonging to Compaq, either.

    Why can't we comment on the article, rather than pick at HeUnique's grammar?
  • Yes, and it works quite nicely (it's quite brilliant really, it will profile an application and actually convert some of the code to native)...unfortunately Compaq canceled WinNT/Alpha support. The Alpha is strictly a *Nix box now (Linux for low end, Tru64 for high end).

    Oh...and I work(ed) for Compaq on the Visual C++ for Alpha/NT product(I'm leaving at the end of the month, for obvious reasons).

    --GnrcMan--
  • While I don't know enough about chip design (and also don't really care) to judge the chips on their technical merits, the bottom line seems to be that it doesn't matter how good a chip you make if you can't ship/sell it in decent volumes. We all know that the early Intel chips were pretty much garbage, yet Intel today is the king of the chip world. Why? Because most (99+%) of the machines sold feature intel compatible chips.

    As long as you can't go to an average computer store and pick up a PPC, Alpha or Sparc chip and build your own computer from it, the general population will not even know they exist. Don't get me wrong: I would like it if all of a sudden the availability of these chips were equal to the Intel chips, but that's just not the reality of the marketplace. With the switch to the 64-bit architecture there may be an opening in the market which will allow these chips to become a more available product in the eyes of the average consumer. But as long as the Intel/MS duopoly (which is showing signs of fracturing) is as dominant as it is now, that's just not going to happen.
  • If Compaq were smart (note the use of a counterfactual conditional)

    Excellent!!! :-)
  • I'll run an alpha KDE, sure. That's one thing. But trust your system to an alpha cpu?? I'll get one maybe after a few months of at least going Beta.

    Oh, ;)
  • There are many organizations that still use VMS for their continuous computing appliations. Alpha is idea for that application.
  • AFAIK, Compaq makes valid points about Alpha vs Itanium, but it's still just a corporate press release. I'm sure Alpha has plenty of drawbacks that the paper silently omits.

    As we all know, product quality is only one (small) factor in product success. Aside from the usual Marketing and FUD wars, the real test will be software support. What OSes, what Apps, what real world uses will run on these chips?

    If a CPU shits in the woods, but no one writes native code, does it make a sound?
  • by / ( 33804 ) on Tuesday December 28, 1999 @04:20AM (#1439783)
    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)
  • Moderate this up as "Score 5: Fucking Hillarious"

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • Sorry, not anymore...I should know, I worked on it!

    --GnrcMan--
  • I think one of the versions of Windows 2000 is 64 bit.

    Conscience is the inner voice which warns us that someone may be looking. [lemuria.org]

  • Looks like Compaq has a chip on its shoulder...
  • 1. It's the other way around. "it's" is short for "it is"; "its" is the possessive pronoun.

    2. The blurb clearly implied that the PDF format was Compaq's.

    3. I had nothing good to say about the article :)
  • Right...If you want the compiler, though, you need a seperate product. But why run NT on the Alpha when there is Linux instead? And with Compaq having released a GEM(Alpha's compiler back-end) based compiler for Linux, it should be really fast!

    --GnrcMan--
  • Getting linux to boot on an IA-64 cannot be done with a quick hack. The IA-64 runs EPIC architecture, not RISC like the Alphas.
  • Right now the Alphas are very pricey, probably largely due to R&D costs. A good Alpha chip will run you about $1500, IIRC. For just the chip.

    If they want some exposure or to compete for the desktop market (Which is where the money is) they need to slash the price on the chips and sell them near cost. Sure they take a hit for R&D but the volume of sales should go up. If they don't have a good strong presence by the time IA64 hits, they may as well close up their doors and go home.

  • FYI (codenames):

    Intel
    Merced: first IA-64 / Itanium (2000)
    Willamette: 0.18-micron cut-down version of Itanium (2000/1)
    McKinley: 1GHz IA-64 / 2MB on-chip cache (2001)
    Madison: 0.13-micron IA-64 high-end workstation/appl. server (2002)
    Deerfield: better price/performance
    Northwood: 3GHz barrier broken (2003)

    AMD:
    SledgeHammer: 64bit K8 ??

  • That darned closed-source programming gets people into bad habits..

    First of all with current versions of Perl the srand call is not needed.

    Secondly I would recommend using qw() because it is more legible for lists.

    Thirdly a little information hiding works well. There is no need to have to synchronize the length of the list with the argument to rand.

    And -w is always worthwhile

    So rewritten we get


    #! /bin/perl -w

    @prefix = qw(Pent It Max Ath Cort Trit);
    @suffix = qw(ium alon ex anium oricon agon on eres obos ymede itan erion);
    @tag = qw(II III IV Pro MMS Deluxe);

    printf ("%s%s %s\n", &rand_elt(@prefix), &rand_elt(@suffix), &rand_elt(@tag));

    sub rand_elt {
    return $_[rand(scalar @_)];
    }


    Not that it matters in this case, but good habits are good habits...

    :-P

    Cheers,
    Ben

    PS To get the code to look like code use the TT tag, and to get indents use &nbsp;. Warning, IE may mess up the indented space on a cut-and-paste...
  • Don't forget that Intel actually manufactures some AXP CPU's! Digital sold their Alpha Fab plants. I think API [alpha-processor.com] makes them as well as Samsung(?) and Intel.

    --GnrcMan--
  • PDF's the format for people who actually want to have a say in how people view their documents. HTML's cool, but it's very limited, typographically and such... There are so many effects you can accomplish via PDF (using Word, Quark, Pagemaker, Illustrator, etc...) that are just impossible to do with HTML...

    Besides which, readers are free for just about every platform (Linux included, I believe... and if the official version isn't available - there's surely an opensource reader....)

    So, get over it!

    :)
  • (from the back of my Miata (DECspeak for Alpha 500a)):

    Model No.: PBPSMIATA

    Tested to comply with FCC Standards

    For Home or Office Use

    This Class B digital apparatus meets all requirements of the Canadian Interference-Causing Equipment Regulations.
    (repeated in French)



    --GnrcMan--
  • While I'm not a programmer and therefore can't really contribute much to the cause, I still wonder why there has been no effort to make an opensource emulator... x86 to Alpha... maybe x86 to SPARC... x86 to PowerPC.... and two way, as well... though i suspect the main use would be to run x86 software on other platforms... Wouldn't that be great? And why is there no effort that I can find?
  • Apologies for potential off-topic.

    Let's port this to all other languages like LISP et al.
    I will do the easy one and port it to C.

    // Copyright (C) 1997 Intel Corporation
    // This is a proprietary Intel C program.

    static const char * prefix [ ] =
    { "Pent", "It", "Max", "Ath", "Cort", "Trit" };

    static const char * suffix [ ] =
    { "ium", "alon", "ex", "anium", "oricon", "agon", "on", "eres", obos", "ymede", "itan", "erion" };

    static const char * tag [ ] =
    { "II", "III", "IV", "Pro", "MMX", "Deluxe" };

    int
    main ( void )
    {
    srand ( 0 );
    printf ( "%s%s %s\n",
    prefix [ rand ( ) % ( sizeof ( prefix ) / sizeof ( prefix [ 0 ] ) ],
    suffix [ rand ( ) % ( sizeof ( suffix ) / sizeof ( suffix [ 0 ] ) ],
    tag [ rand ( ) % ( sizeof ( tag ) / sizeof ( tag [ 0 ] ) ] );
    return 0;
    }

    P.S. Yeah, I know, I should write a perl to C printer, but then the post would be too long.

    For I am not master coder yet who can code a super short compressed one-line self-compiling compiler to fit as a post.

    Any challenger care to respond with one?

    P.P.S. Back to doing some real coding. :)

    Corrinne Yu
    3D Game Engine Programmer
    3D Realms/Apogee

    Corrinne Yu
    3D Game Engine Programmer
  • You are right

    --GnrcMan--
  • No...Win2K is currently a 32 bit platform. Even the Alpha versions were the same 32 bit platform. Nt64 is in development.

    --GnrcMan--
  • I hear it already runs on IA64. Apparently Intel has been dumping quite a few resources into ensuring that this is the case.

    --GnrcMan--
  • Easy way to remember this:

    the possessive form does not possess an apostrophe.

    so, the possessive form isn't.

  • Uhhm...try this:

    Main Entry: order of magnitude
    Date: 1875
    : a range of magnitude extending from some value to ten times that value

    and

    Main Entry: magnitude
    Pronunciation: 'mag-n&-"tüd, -"tyüd
    Function: noun
    Etymology: Middle English, from Latin magnitudo, from magnus
    Date: 15th century
    1 a : great size or extent b (1) : spatial quality : SIZE (2) : QUANTITY, NUMBER
    2 : the importance, quality, or caliber of something
    3 : a number representing the intrinsic or apparent brightness of a celestial body on a logarithmic scale in which an increase of one unit corresponds to a reduction in the brightness of light by a factor of 2.512
    4 : a numerical quantitative measure expressed usually as a multiple of a standard unit


    Seems like they have an inkling. :)

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

    It's the other way around, really, with Intel trying to get into Alpha's market. I say this mainly because I don't believe that either chip is going to be aimed at anything but the server market for a long time...
  • I'm sure everyone noticed the portion of the doc that mentioned that proper use of the IA64 platform could inflate the size of binaries by almost 33%

    33% ??

    I guess Intel really is a 'Microsoft Strategic Partner! They're helping them with code bloat!!
  • by AugstWest ( 79042 ) on Tuesday December 28, 1999 @05:26AM (#1439876)
    uh, it's gramm a r.
  • Tough call here... Either you're not Corrine Yu, or you haven't updated your user info/sig line in a damn long time.
  • This is normal. In order to get more optmisation, the binary sizes _will_ increase. It does when you enable optimisation with gcc like -O6, this is hardly a new thing, but I'm not sure if it's due to the pentium(or itanium)'s design.
  • I can't help get the feeling that the chip get it's name from the Curator of the Planitarium in South Park.

    "welcome to the Plani-arium"

    Vs

    "Our new chip will be called: I-anium!"
  • by G27 Radio ( 78394 ) on Tuesday December 28, 1999 @06:14AM (#1439906)
    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
  • While calling me clueless is not very nice, you are right. I spaced and forgot VMS. In fact, a pretty big chunk of the ARM details the VAX PALCode instruction set for the Alpha. See, I'm not clueless. My clue generator simply needed a kick after just waking up.

    I should hope I know something about this. I helped write the damn Alpha compiler for Visual C++.

    --GnrcMan--
  • Think proprietary...

    Is WOrdperfect for Linux available for AlphaLinux, LinuxPPC, and UltraLinux (is that the sparc version)?

    Oracle8

    Informix

    Sybase

    and mostly every other non-opensource program for linux will probably target x86...

    Thanks for the info, though!
  • Alpha costs more? When's the last time you priced a top of the line Intel Xeon? I found a PIII Xeon 550/2MB priced at $ 3795.95 - and that's just the processor! (and these guys are cheap!)


    Compare apples to apples. A full system with a PIII 500MHz is around $2500-$3k including a complement of RAM and hard disk space. The top alpha is ONLY available from Compaq. The fast motherboard is the XP-1000 for about $10k without the RAM or monitor. And add-ons for the Compaq alphas machines are EXPENSIVE. One generation late you can get a 21164 processor which is still fast in a machine for about $3k. Video card support under OSF or alpha linux is very poor. Unless you really need the supercomputing, it just doesn't make a lot of sense to buy an alpha. Now, if Compaq somehow made third party peripherals supportable for alphas they would sell a WHOLE lot more alphas without losing the number crunching crowd.
  • Not available?

    Sure, the chips are expensive, but what Alpha processors need is marketing not necessarily pricing.

    And 99% of computers are shipping with Intel processors? Guess you missed AMD having the majority of computer sales a couple months ago (at over 40%) or the iMac's surprising success.

  • by Jim.McGinness ( 38527 ) on Tuesday December 28, 1999 @06:37AM (#1439921) Homepage
    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.
    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, ...) is x86 only. If you need any of those, An alpha is not the right choice for you.
  • by Jeff Mahoney ( 11112 ) on Tuesday December 28, 1999 @07:11AM (#1439935)
    ``Insanely idiotic OS''??

    Maybe you'd have a leg to stand on if Linux supported the enterprise features that Digital UNIX does.

    Unfortunately, it doesn't.

    Example: High performance, dynamically resizable, journalling filesystem.

    Does Linux have it? No. I'm familiar with the efforts that exist to address this, I work with one of the authors of a major project for this. He'll admit that ext3/reiserfs doesn't touch ADVFS.

    Example: Advanced high availability clustering solution with a shared filesystem among nodes, cluster aliasing, and context-dependant symlinks for a SINGLE disk image shared amoung up to 8 cluster nodes.

    Does Linux have it? No. Be aware that Beowulf is NOT an HA solution - it's a distributed computing cluster.

    Perhaps you should do some more research before blindly bashing an OS that has features that Linux has yet to dream of.

    As a side note, the Alpha isn't only used for supercomputing. I'm part of a group that runs 3 clusters of AlphaServers for everything from mail, web, and database serving. Only recently did DEC/Compaq enter into the supercomputer arena with the ``SC'' series of Alphaserver.

    Your typical DS/ES/GS series AlphaServer may not be meant for your average joe-blow computer enthusiast, but 14 processors does not constitute a supercomputer. The new ``SC'' series AlphaServer that DEC recently released is a 64-512 Alpha CPU model. THAT is a supercomputer.

    I've been using Linux since 1995, and Digital UNIX since 1996, so I've got a pretty good feeling on the comparisons between them.

    -Jeff

    Moderate this down as flame bait if you like - but I have a feeling that most readers have never used Digital UNIX/Tru64, and don't have enough knowledge of it to form a good opinion.
  • 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.

    I seriously doubt a consumer is going to want an Itanium. Or even an Alpha. These chips are designed as server and technical computing workhorses.

    Like with the Alpha, all the operating systems and applications will need to be ported to the new IA-64 architecture to see any useful speed gain. All reports indicate that the on-board x86 compatibility is dog slow, with no appreciable performance gain over Pentium or Athalon chips. Why should gran'ma buy a $5000 Itanium box when the $999 iMac will run rings around it when running Quicken or MS Office?

    Then there is the issue of native software: Linux, and NetBSD are gimmies. HP-UX is going to be forced marched to IA-64 (HP originally developed EPIC for the HP9000). IRIX and SCO are "definite maybes".

    Sun and Microsoft, on the other hand, will probably port their OS to the platform in hopes of killing it. Microsoft had ports of NT on x86, PowerPC, MiPS and Alpha. Only x86 remains. Like with the older RISC architectures, MS will port and support the platform for a little while, but won't port it's applications, and won't promote their OS on anything other than x86. This way, Microsoft can keep control of their hardware market, and deny competitors popular support for their primary platform. And, when the market drops out, MS can quietly discontinue NT for IA-64, and place the blame squarely on Intel; just as they've blamed Compaq, Apple, and SGI for the failure of NT on RISC. Sun has a cross-platform strategy with similar goals: get them hooked on Solaris, and then entice them over to SPARC, where the applications are.

    MS likes x86 becuase it -owns- x86. Linux will always be an also-ran on x86: merely a "Hobbyist's OS". The blind loyalty to intel and x86 I find expressed here is disconcerting. The only thing that will allow Linux to overcome proprietary systems is -ubiquity-, and that means cross-platform parity. Use the fastest and the best when available. That, more often than not, means Alpha.

    SoupIsGood Food
  • It's very simple really. Check out this article [salon.com] in Salon for details.

    cjs

  • by Dahan ( 130247 ) <khym@azeotrope.org> on Tuesday December 28, 1999 @07:23AM (#1439944)
    A couple months back, Compaq had a deal where you could get a DS10 (466MHz 21264) for $3K. Certainly not as fast as the XP-1000, but not a bad price. Looks like the price is up to $3800 now...

    Previous generation PC164 motherboards were (maybe still are) selling for around $250, including a 500MHz 21164A. Just add an ATX power supply, case, 4 or 8 72 pin parity SIMMs, a hard drive and you have yourself a computer :) (I guess video and network would be nice... it's got ISA and PCI slots). I got myself one of those in May:

    • PS and case: $60
    • 4 32MB SIMMs: $260
    • 2 gig Quantum Atlas I (fast wide): had it lying around
    • Symbios 53c875 UW SCSI card: $65
    • generic Trident PCI SVGA card: $15
    • D-Link DFE-530TX 10/100 ethernet: $15
    I've got mine running NetBSD... works great :) Recently got another 4 32MB SIMMs (they were like $45 a piece) for a total of 256MB. It's slower than the latest x86 stuff out there, but not that much slower... and don't forget, this motherboard came out in like 1996 or so.
  • by edhall ( 10025 ) <slashdot@weirdnoise.com> on Tuesday December 28, 1999 @07:57AM (#1439963) Homepage
    Since the Pentium Pro, there has been the ability on Intel chips to address more than 4GB of ram.

    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.

    -Ed
  • Any links on this? Anyone used it?

    Yes, it's called em86.

    I dug up the info from the alphalinux faq. I've used it myself, however I had no luck with icecast when I tried running it emulated. There were a lot of other issues so I'm not sure that em86 was at fault. That's about the extent of my personal experience with it.

    http://www.alphalinux.org/faq/FAQ-16.html [alphalinux.org]

    numb
  • Following the suggestion, here are a few ports of the above program to some popular languages (substitute underscores for spaces when obvious):


    * 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 :P
  • This is really no big deal, except maybe for gargantuan products like MS Office. The Mac platform went through this same thing when switching from 680X0s to the PowerPC chips. The code for CISC-style chips is almost always more compact than code for RISC-style chips -- that's just the natural of the instruction sets.
  • I'm not saying that they're using it because it might support this or that, but wouldn't it be nice if there was that option???

    If x86 Linux is headed towards the mainstream, then it's RISC cousins need to be able to have a mechanism in order to use all the software available to x86, otherwise they'll always be treated as second rate to x86.

    And yeah, running Oracle in emulation would be just dumb... but for something not as performance hungry, like WordPerfect or Opera, it'd be nice to have the option, i'd think...
  • It's worth noting that the Pentium Pro/II/III have a 48-bit segmented addressing mode, allowing physical memory beyond 4GB. Nobody uses this yet, but it's in there.

    Maybe FreeBSD makes use of it

    Almost certainly not. You do not have to use the segmented addressing more to access more than 4GB of physical memory - you may not be able to have all of it mapped in at the same time, but you could map it in and out dynamically, or give 4GB-or-less chunks to various processes.

    In fact, the x86 segmented mode - which is not new in the P6 processors (PPro, PII, PIII), but has been around in its current form since the 386, and existed with smaller addresses in the 286 - doesn't even help. The x86 MMU maps 48-bit segmented addresses (which any OS running in protected mode uses, although most of them set up "trivial" segments and, unless they're running 16-bit programs that use 286-style segmentation to boost their address space size, don't really make use of it) to 32-bit linear addresses; those 32-bit linear addresses are then translated to physical addresses through the page table, if paging has been enabled (which it is, in most x86 OSes, e.g. Windows OT and NT, OS/2, Solaris, Linux, BSD, etc., etc.).

    What's new in the P6 processors is the ability to specify page tables that generate 36-bit physical addresses rather than 32-bit physical addresses (an ability that at least some other 32-bit processors, e.g. SPARCs with the SPARC Reference MMU, have had). You need that ability and you need a memory bus that puts out more than 32 bits of physical address; I think some 32-bit platforms have had that, and some high-end "PC" platforms may have it.

  • Can't take that much credit. Compiler optimizations are done in the GEM backend which is written by a briliant team in New Hampshire. The VC/Alpha compiler used the Microsoft parser and a translator which wrapped around the GEM library. The real magic is in GEM. I was working on Backend/optimizer code at the time NT/Alpha was cancelled, so that code will never see the light of day. Incidentally, you get the same technology using the compiler that Compaq has now released for Linux [digital.com]. Sadly, this is not open sourced, which is unfortunate.

    On the upside, Starting in the next month or so (After I officially leave the VC/Alpha project) I plan on fooling around independently with EGCS on my Alpha box at home. I'll certainly contribute what I can.

    --GnrcMan--
  • BEGIN {
    srand()
    split("Pent It Max Ath Cort Trit", PRE)
    split("ium alon ex anium oricon agon on eres obos ymede itan erion", SUF)
    split("II III IV Pro MMX Deluxe", T)
    b=rand()*100; c=rand()*100; d=rand()*100
    CONVFMT = "%2i"
    a=b ""
    x=c ""
    y=d ""
    printf "%s%s %s\n", PRE[a%6 + 1], SUF[x%12 + 1], T[y%6 + 1]
    }

    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • I spend most of my day laying out pages using Quark.... A lot of these pages also need to be available online, and we've found that the best way to do so, when formatting is an issue, is to use PDF's.

    CSS is relatively new - yes, the spec's been out for a while, but only now do most browsers have somewhat decent support for it. And Mozilla I wouldn't even consider, being that it's pretty much Alpha software... I haven't ventured to try it with Linux (because at this point i feel Linux is best suited as a server OS), but on the Mac, Win 9x, and Win NT, I've found it to be horribly unstable. I also haven't fully investigated Opera, which leaves us with just Netscape and IE...

    Of those two, IE seems to more fully implement CSS... version 5 is much better than 4.5, but 5 is Windows only where as 4.5 was also available for the Mac.

    Acrobat reader is available for probably as many or more platforms as Netscape Communicator/Navigator. It also (Thanks to QuarkXPress) has MUCH better typographical control than CSS. That's probably because the programs being used to generate PDF's are much more mature than those used to genertate HTML, XML, etc...

    You can't generate ligatures with CSS... nor can you have nearly as wide a choice of fonts... With PDF, I don't care what font's you have available, because i can embed them within my document. And also, using PDF's, you're extremely unlikely to need to tinker with the file/code at all, where as anything where detail is that much an issue in HTML, you always need to wade through the code.

    So, to summarize... The tools to generate PDF's are much more advanced than the ones to make CSS/HTML. The tools to view PDF's are also much more advanced than those currently available for HTML, in that the designer/author has so much more control over the final appearance of their document than can ever be achieved with CSS/HTML... Yes, I could specify that i'd like this font to appear as Adobe Bembo, but if that's not available on your machine, you may end up with Times, or whatever generic Serif font is available.

    That's all in my opinion, of course..
  • You do
    not have to use the segmented addressing more to access more than 4GB of physical memory

    That should've been "You do not have to use the segmented addressing mode".

    As per my parenthetical note, you do, in a sense, have to use it to use paging, but you don't have to use it in a non-trivial fashion; most (if not all) x86 OSes don't use full 48-bit addresses, they just use 32-bit addresses with implicit segment numbers, and set up the segments to overlap so that those 32-bit addresses translate trivially to 32-bit linear addresses.

    As for FreeBSD vs. NetBSD, I think none of the BSDs map the entire kernel address space into virtual memory; I don't think Solaris does, either - I think they added support for >4GB of physical memory in 2.6 or 7.

  • by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Tuesday December 28, 1999 @09:13AM (#1440001)
    The Alpha, MIPS, and PowerPC architectures date from the era when the goal was one instruction per clock cycle

    MIPS does; however, POWER and Alpha may not. The first POWER and Alpha processors were superscalar (PowerPC being a descendant of POWER).

    It's worth noting that the Pentium Pro/II/III have a 48-bit segmented addressing mode, allowing physical memory beyond 4GB.

    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.

    It would be a coup for some Linux vendor to support this, allowing Linux PC-type machines bigger than 4GB.

    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.

  • So that would mean you've looked/worked on the NT source right? Is it really as bad as everybody claims it is? Would you trust your life's work to this OS? Inquiring minds want to know!

  • ``Insanely idiotic OS''??

    Lay down the crack pipe and take a deep breath and read what I wrote again. Insanely idiotic OS and component licensing scheme. The licensing is insane, not the OS.

    Maybe you'd have a leg to stand on if Linux supported the enterprise features that Digital UNIX does. Unfortunately, it doesn't. Example: High performance, dynamically resizable, journalling filesystem.

    AdvFS cannot be fscked. This in turn has fscked me. Get the picture. If the FS breaks, you keep both pieces. Thank you Digital for such a wonderful advance in computing. Bad inodes just get to live indefinitely on your system until you copy all the files to a different partition (dump and tar choke), and reformat. We haven't had such advances since, well, DOS. Needless to say, we are going back to UFS for our OSF needs, which is only quite a bit slower than ext2. But at least when it breaks we can fix it.

    OSF also doesn't ship with a reasonably modern interface. CDE, MWM, and TWM are simply not enough.

    It certainly has its niche for ultra high end computing where user interfaces are just not viewed as important. But the OS is chock full of holes. And I run into them from time to time.

    Example. glibc call for wordexp does a complete shell-like expansion in C. Libc shipped with OSF does the expansion by shelling a command to ksh. Why should libc depend on ksh for its integrity ??

    Example. Recursive scripts fill up the process table and lock the system in OSF. Not so in linux.

    There are also good things. CC is a really fast compiler. So is the ForTran compiler. If you want to run processes real fast, OSF is a good choice. If you want a large number of CPUs, OSF is a good choice. If you want a decent user interface, reasonable speed, and a journaled file system that can be fixed, linux is a good choice.
  • I could tell you...but I'd have to kill you. Seriously, though I've seen a small part of the NT source code, I worked on the compiler(Visual C++ for Alpha). So I'm in no position to comment, even if it wouldn't bring the wrath of MS apon my head. I will let you in on a little secret though. At home I run Linux. :)

    --GnrcMan--
  • The Alpha, MIPS, and PowerPC architectures date from the era when the goal was one instruction per clock cycle and a nice, simple CPU with a fast clock.

    Bzzzt..wrong. From the Alpha Architecture Reference Manual, preface, first edition:

    We concluded that the remaining factor of 100 would have to come from other design dimentions. If you cannot make the clock faster, the next dimension is to do more work per clock cycle. So the Alpha architecture is focused on allowing implementations that issue many instructions every clock cycle.

    down the page a little:

    These three dimensions therefore formed part of our design framework:
    * Gracefully allow fast cycle time implementations

    * Gracefully allow multiple-instruction-issue implementations

    * Gracefully allow multiple-processor implementations

    It goes on to list specific design decisions made to meet these goals. When they designed the Alpha, they had a 25 year design horizon. BTW, that preface was written in 1992.

    --GnrcMan--
  • 64-bits buys other stuff, too. For example, larger file systems. Most 32-bit OS'es give you a 2GB or 4GB file or volume size because that conveniently fits in their 32-bit integers. But things get dicey when you start working with digital video, large databases, etc. because you start hitting those limitations. My biggest problem [off topic] with 64-bits is that nobody writes good 64-bit safe code. Any time I try porting some 32-bit package to my dearly loved Alpha's I get nailed by idiots casting 64-bit pointers to 32-bit ints. People, please don't assume sizeof(long) == sizeof(void *)!
  • If memory serves me correctly, <pre></pre> was once supported by Slashdot... and abused horribly by AC's who would use them to force horizontal scrolling (imagine a loooooooong string between <pre></pre>)... damn annoying.

    But yeah, it would be nice for code posting. Oh well, just another example of a few sh*t-heads screwing things up for everyone else...
    ________________________

  • by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Tuesday December 28, 1999 @12:23PM (#1440042)
    P6's can use various tricks to access more than 4GB, but only by using yucky segmentation techniques.

    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.

  • but you've neglected to mention that you can get (and use) a full 64 bit word from that address with a 64 bit OS

    You can do that on 32-bit machines as well; most memory fetches tend to turn into cache-line fills, which can use the wider-than-32-bit data buses available on most if not all general-purpose-computer 32-bit processors these days.

    You typically can't process all 64 bits of that word - at least not with integer instructions - but you at least get all 64 bits (or more, if your memory bus is wider) at once.

  • by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Tuesday December 28, 1999 @12:29PM (#1440045)
    The biggest advantage of 64 bit is the ability to operate on Quadwords (64 bits)

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

  • One is the ability to address more than 4GB of physical ram (which 32bit addressing is limited to)

    32-bit addressing is limited to 4GB of physical RAM at any instant, but you can handle more than 4GB of physical memory in multiple 4GB-or-less process address spaces, or handle it by mapping pages in and out of a given address space, on a platform with 32-bit virtual addresses.

    Linux already does this on alpha's.

    ...and there's a patch from, as I remember, Siemens, which, as I remember, was accepted for the 2.3 kernel, to do that on x86, presumably in the fashion I described.

    The ability to seek more than 4GB into a file (ie: fseek takes a 64bit offset, not a 32bit one). I'm pretty sure alpha linux has this too.

    ...as does x86 {Free,Net,Open}BSD, versions of NetBSD and OpenBSD on other 32-bit platforms, Solaris 2.6 and Solaris 7 on x86 and 32-bit SPARC, etc., etc., etc....

    ...and on Linux, with the right patch; I think that patch has also been accepted for the 2.3 kernel.

    A 64-bit architecture run in 64-bit mode isn't necessary for handling more than 4GB of memory, or for seeking more than 4GB into a file - fseek() may take a 32-bit offset on those platforms, but fsetpos() could take a 64-bit offset, as could llseek(), say - but it does make it a bit more convenient (no need to muck around with mapping stuff into or out of an address space, no need to use on UNIX all the extra stuff from the Large File Summit, or to use the somewhat clumsy support in Win32 for file offsets >32 bits).

  • What I read about many times before is MS would not change NT from it's current state (leave the OS 32 bit), but build an "emulator" that would run as a layer between NT and the hardware that would make the hardware believe NT was 64 bit.

    That's how it runs on Alpha - 32-bit address space and, I think, 32-bit page table entries. On Alpha you can do 32-bit page-table entries by doing NT PALcode, as, on all existing Alpha processors, TLB misses are handled in software (well, PALcode, but that's just software loaded into memory from a ROM, running in a special mode that lets it get at processor-specific internal registers), so the software (PALcode) can control what PTEs look like.

    I don't know whether IA-64 will do that or not.

  • by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Tuesday December 28, 1999 @12:47PM (#1440052)
    Try reading the man pages for
    verify and salvage. AdvFS does not need fsck.

    ...but it does need a salvager; I infer from the name that salvage is a salvager for AdvFS, just as fsck is a salvager for, for example, UFS.

    So the original poster was right in his belief that file systems without salvagers are bad (anybody who believes otherwise either believes that restoring from a backup tape is Always The Right Answer, a claim of which I'm rather skeptical, or believes that disks, disk firmware, and file system software breaks sufficiently rarely that it's not an issue, another claim of which I'm rather skeptical), but wrong, apparently, in his belief that AdvFS lacks one.

  • Yep, yer right. I actually don't use Python very often myself... sorry about that. It runs now, though, right? :)
  • Yup. You don't need a 64-bit processor to do 64-bit integer operations; however, you're likely to be able to do it faster on a 64-bit processor.

  • Actually, for true multithreading, check out Tera supercomputers. Hardware support for multiple threads means threading is broken down to the instruction level.
    The Convex had threading in hardware as well. That meant you had assembly level instructions like fork and join. It was interesting work. And Convex was a 64bit BSD way back in the 80s. And Cray had a 64bit SysV, too.
  • I bet most people here won't catch your implicit reference to "All the world's a Vax". It's amusing that this should come out of The Company Formerly Known as DEC. The pain of the 16-bit PDPs to the 32-bit Vaxes was bad enough.

    On another thread here, regarding the mistaken notion that a machine with 32-bit pointers can't hold more then 2**32 memory, it seems to me that an 11/70 would allow more than 64k of memory per machine, but would only let you map in 64k per process.

  • 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)

    Yes, 2.4 BSD allowed for overlays, as did RSX/11. This was a matter of the OS reloading some segmentation registers on request. Pentia could do similar things via the page table, should someone care to add the necessary OS calls. But it was yucky even back then. I've recomitted those brain cells to other tasks these days.

    -Ed

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Working...