Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Hardware

HP Finally Reveals The Alpha Marvel 152

brejc8 writes "HP have revealed the new range of AlphaServer systems. The new EV7 processors show very reasonable performance figures. Revealed by the inquirer the 1GHz versions have very similar SPEC scores as the 1GHz Itanium 2 (INT_2000 of 875 and FP_2000 of 1,500). This is very intersting after HP were rumoured to ensure that "...no Alpha benchmark will be released until the Itanium platform(s) is/are faster"."
This discussion has been archived. No new comments can be posted.

HP Finally Reveals The Alpha Marvel

Comments Filter:
  • linux? (Score:2, Insightful)

    by tps12 ( 105590 )
    Any word on whether these babies will run Linux? That's probably going to be the single biggest factor in deciding which 64-bit server CPU dominates the marketplace.
    • Re:linux? (Score:4, Informative)

      by 1lus10n ( 586635 ) on Monday January 20, 2003 @02:32PM (#5120260) Journal
      they should, all current versions of the alpha procs run linux great. (as verified by the alphaserver 5000 sitting under my desk running RH 7.2)
    • Re:linux? (Score:5, Informative)

      by Compaq Test Drive ( 560243 ) on Monday January 20, 2003 @02:51PM (#5120389) Homepage
      Speaking as someone who has in fact actually done it, yes, Linux will run on an EV7 Alpha system. If you'd like to try out an EV7 prototype system, we have one up in the HP Test Drive Program [hp.com], where we give out free shell accounts on a wide range of hardware and operating systems. The EV7 prototype we have is running Tru64 UNIX at the moment, but we do periodically have Linux on there for people to try. We also have Itanium II systems running Linux, for anyone who would like to try them out as well.

      I may work for HP, but that does not imply that my opinions are theirs.

      • Whooha. That's a mighty interesting service. I just wonder whether it is remotely safe to test our software on there. Perl-based, uses database and a web browser. I reckon everything we do can in fact be set up and compiled within a shell account - except running on standard ports :) But how safe is the service?
        • Except for the telnet ports, no outbound connections are allowed and/or possible on the testdrive program. So your request for opening reachable ports so you can run a web browser will probably be useless.

          It _is_ nice to check if your code will compile/work/parse or of course break on those platforms though. I am a happy user. Thanks Compaq^WHP!

    • If it doesn't run linux a port's only three nanoseconds away!
    • Re:linux? (Score:3, Informative)

      by doorbot.com ( 184378 )
      That's probably going to be the single biggest factor in deciding which 64-bit server CPU dominates the marketplace.

      Linux on UltraSparc works great, and has excellent support under Debian (although I guess that's no surprise).
      • Re:linux? (Score:2, Interesting)

        Sure it works great. Unless you care about POSIX sigcontext. In which case the SPARC/UltraSPARC Linux kernel sucks like a Hoover. And yes, the SPARC kernel developers know about it, and no they don't give a damned. It's the only version of the Linux kernel with a broken sigcontext implementation.

        Oh, and GCC still doesn't support all of UltraSPARC's 64-bit instructions. And no, Linux distros for UltraSPARC don't come compiled 64-bit. And last I checked (a couple months ago) I still couldn't get glibc to compile in 64-bit mode on Linux/UltraSPARC. It just choked somewhere in the middle of the build due to broken code generated by GCC.

        Linux kicks ass over Slowlaris and SunOS when run on 32-bit SPARC processors. But when it comes to 64-bit UltraSPARCs it simply bites. And nobody seems to care enough about the lack of performance or support to make it better.

        But Linux/UltraSPARC does make a good web server or the like. An Ultra 5 doesn't cost too much more than a similarly rated PC and is essentially immune to all r00tkits because the script kiddies don't have tools for Linux/UltraSPARC. For Linux/x86 yes, and for Solaris/UltraSPARC, but not for Linux on an UltraSPARC. You just get a weird message in your logs and the program in question just dies quietly.
    • According to what I read in Financial Times Deutschland (FTD), they will. AMD also see Linux as serious OS for their new 64-bitter as they fear that Microsoft may not be finished in time.
  • See Also... (Score:2, Interesting)

    by Anonymous Coward
  • Only one? (Score:5, Funny)

    by LiftOp ( 637065 ) on Monday January 20, 2003 @02:31PM (#5120254) Homepage
    from hp: "Customers, analyst and industry leaders react enthusiastically"

    I knew tech was tightening the belt, but they could only get one analyst to react enthusiastically? And you know that guy's looking over his shoulder... I'd be reacting DAMN enthusiastically if I was him.

    • That reminds me of how easy it is to get an "enthusiastic reaction". When I worked for Spin Records, we always heard how "potential customers reacted enthusiastically to" this and "got very enthusiastic feedback" from that. One of the investors was a group of Hassidic Jews, I wonder how much "enthusiasm" they got there.

      But it just reminds me of the old TV gag, where they put up a taste test of lemonade and put the cameras in plain view. Only its not lemonade, its lemon juice. You watch the people fight sour expressions to extoling their enthusiasm about the product, just for their 15 minutes.

      I'm not overly pessimistic here or anything, but when you mentioned "looking over his shoulder" thats what came to mind.

      ________________________________
      OnRoad [onlawn.net]: Tempering detroit iron with our own hot air since, well, last week.
  • HPs Strategy (Score:5, Insightful)

    by jbischof ( 139557 ) on Monday January 20, 2003 @02:36PM (#5120290) Journal
    I am very confused on why HP says "We fully support Itanium" and then releases EV7? This architecture is so fundamentally sound that it can beat Itanium 2 on core floating point performance.

    In my mind HP should either go one way or the other, not release a processor most people would claim to be better than Itanium. Why didn't Intel just buy the Alpha architecture and continue it?

    I know that AMD and Intel have both dissected the EV8 planned processor, and used parts of it for themselves. EV8 was going to be 4-way SMT (Intel uses that now as HyperThreading) and have integrated Northbridge on die (same as Hammer chips).

    Its a sad state of affairs when the superior architecture gets cut up and sold to different companies to produce two slightly inferior chips.

    • Re:HPs Strategy (Score:3, Informative)

      by Anonymous Coward
      They need 'grout' to fill in the space between people currently on Alpha (or someone needing better performance NOW), before Itanium comes to the point in which they are the in thing. Alpha has MANY VERY loyal customers that would drop ship if they didn't have something to fill the space until Itanium comes of age. AMD doesn't have anything on EV8, it is EV6 they have and licensed technology for. Intel does however have rights to use everything from EV7 and EV8.
    • Re:HPs Strategy (Score:5, Insightful)

      by Chris Colohan ( 29716 ) on Monday January 20, 2003 @02:59PM (#5120440) Homepage
      Before HP purchased Compaq, Compaq had already committed to selling EV7 systems to customers. HP would be stupid to reneg on those contracts and upset their customers.

      Also, when HP bought Compaq years worth of design work for the EV7 were already finished. Throwing it away would not necessarily be a profitable decision.

      Talking to the folks on the Alpha design team (now the Intel advanced design team), they were not super happy about EV8 being cancelled. But such decisions usually come down to money...

      The Alpha was in almost all ways a technically superior design to the IA-64. Now that the same group of architects is working for Intel, they can probably make the IA-64 run almost as well or better...
      • Now that the same group of architects is working for Intel, they can probably make the IA-64 run almost as well or better...

        Your assumption is that the Itanium architecture is as extensible, or more extensible than the Alpha. I'm no processor expert, but I would guess the Alpha engineers will do an excellent job on the Itanium. Will they be able to make the next Itanium better than the EV8? Hard to say... for one, the Itanium is a whole new design (compared to the Alpha, and compared to the rest of PC processors).

        Hopefully a microprocessor guru can add some insight...
        • Re:HPs Strategy (Score:2, Insightful)

          by Anonymous Coward
          the next itanium will be better than ev8 for 2 simple reasons: ev8 doesn't exist; and it will never exist. process improvements alone are enough to be "better" than any non-existant EV8
      • Re:HPs Strategy (Score:4, Informative)

        by Isle ( 95215 ) on Monday January 20, 2003 @04:43PM (#5121301) Homepage
        A great deal of Alpha architect left when Compaq bought Digital. They went mostly to AMD, making the Athlon faster (the main-design was already done), and their influence is also seen readily in the Sledgehammer design.
      • Re:HPs Strategy (Score:3, Insightful)

        The Alpha was in almost all ways a technically superior design to the IA-64. Now that the same group of architects is working for Intel, they can probably make the IA-64 run almost as well or better...

        The fact that you have superior designers working on fixing up an inferior spec does not mean they can work miracles. When you start with something that is not as good, you will spend a lot of time catching up - time that could have been used to better an already good platform.

        So, instead of a great Alpha, you'll end up with an as-good-as-the-old-Alpha Itanium.
      • When Digital went to Compaw and Compaq went to HP, one thing followed and that was US govt contract commitments. Even a commitment to a major bank or other financial organisation counts little against a contract with the DoD. The banks have been presented with a ten year plan including the migration of VMS from Alpha to Itanium and VMS has at least another 15 years to run. Compaq-Digital has told us that they have firm obligations to the DoD that prevent them from changing this.

        The sad news is no EV8. Itanium is far from being debugged and doesn't seem to be a particularly clean architecture compared with Alpha and Intel aren't particularly innovative.

    • Re:HPs Strategy (Score:3, Insightful)

      by brejc8 ( 223089 )
      Big server companies cannot just drop products. There would be so much of an outcry that no one would buy the next range from then because they could drop that too.

      EV8 was a finished product when the lots of compaq hp stuff started happening and so hp wouldnt kill it of after all that money being put into it. hp decided to suck up to intel forever now and supporting the remenents of the alpha while it makes money is still a good idea to them.

      The last reson is that compaq employees would be a little hurt and dissatisfied if hp went along and killed every product they had.

      Its a shame that hp dont want to push the alpha and that it was a little delayed due to the transition. If it was released a few months ago hp would have probably kept the line open for a few years longer.

      • Re:HPs Strategy (Score:3, Insightful)

        by rodgerd ( 402 )
        Forget the outcry - most of them have contractual obligations. In the case of the Alpha, a number of Alpha based supercomputers exist where DEC/Compaq/HP have a contractual obligation to provide new generation Alphas with particular performance requirements.
    • Re:HPs Strategy (Score:3, Informative)

      by heh2k ( 84254 )
      In my mind HP should either go one way or the other, not release a processor most people would claim to be better than Itanium. Why didn't Intel just buy the Alpha architecture and continue it?

      they were probably well into working on the itanic when the option to buyout alpha came along.

      Its a sad state of affairs when the superior architecture gets cut up and sold to different companies to produce two slightly inferior chips.

      yes, it is. and disregarding alpha for a moment, you would think after 20 so years of the pile of crap known as x86, that intel would be intelligent enough to make clean, sane cpu. instead they, of course, design the itanic. i've read about its isa and all i can say is "feature bloat". i also read a little of the hp book about porting linux. the itanic is the most overly complicated, misdesigned cpu i think has ever been made. at least when the 8086 came out, it was a good design (relatively speaking).

      it's funny how intel says "epic is simple, no ooo complexity" but doesn't mention the all rediculous crap like rotating register files, etc, etc. afaict, ia64 is MORE complex than any risc chip. NOT simpler. and throwing ooo out the door is stupid. a) compilers can't predict cache misses b) gcc sucks and so, to get anywhere near decent performance, you have to use a different compiler (dec's cc, and i think just about everyone else's, outperforms gcc). i predict that intel will be forced to eventually add ooo back. at best, intel has traded ooo complexity for the complexity of all the features needed for compiler driven scheduling, AND forced compilers to be very good just to get decent performance.

      • Re:HPs Strategy (Score:3, Interesting)

        by jbischof ( 139557 )
        it's funny how intel says "epic is simple, no ooo complexity" but doesn't mention the all rediculous crap like rotating register files, etc, etc

        Rotating register files and lots of the other features that Itanium has, aren't inherent in their ISA. There is nothing in EPIC that says you need rotating registers. These are just things that Intel thought would be really useful and people haven't started exploiting yet.

        I think they had a good idea when they designed the ISA, but botched it a little bit on the cpu architecture. However, as compiler technology advances and software starts taking advantage of the "feature bloat" I think we will see a drastic improvement in Itanium performance.

      • Re:HPs Strategy (Score:2, Interesting)

        by TheRaven64 ( 641858 )

        it's funny how intel says "epic is simple, no ooo complexity" but doesn't mention the all rediculous crap like rotating register files, etc, etc. afaict, ia64 is MORE complex than any risc chip

        Rotating register files are part of the original RISC II architecture. The Itanium has some fundamentally good design features. In a standard superscalar chip, a missed branch results in a pipeline flush, which is a huge overhead. In Itanium, all instructions are predicated, so most branch-like structures cease to exist, and instructions which are speculatively executed can simply not be retired. This can lead to a significantly higher instruction throughput. The rotating register files concept is a very good one, as it allows functions to be called without having to write registers to memory (which is slow) or cache (which is not fast).

        Perhaps with regard to compiler support, Intel will follow Apple's route (which, is by definition good, since Apple are doing it) and contribute code to gcc (In Apple's case to improve AltiVec support). After all, if Linux runs faster on an Itanium, it would only help Intel sell more chips, which is what the enjoy doing most.

        The Alpha has some very nice features, but slating the Itanium architecture because the Itanium and Itanium II (both of which are really intended as proof-of-concept demos rather than commercial CPUs is ludicrous.

        • Re:HPs Strategy (Score:4, Insightful)

          by Bert64 ( 520050 ) <.moc.eeznerif.todhsals. .ta. .treb.> on Monday January 20, 2003 @08:17PM (#5123144) Homepage
          The Itanium 1 was a concept chip, the second one was meant to go into general use.. it has failed, so people label it a concept chip to try and save face..
        • While I'm not against Intel contributing compiler code to the open source community I doubt it would go into gcc. EPIC is so different from all of the other gcc target platforms that core changes would need to be made to the compiler that would work well for EPIC code but which would not at all produce good results with say the SPARC backend. This is one of the largest problems facing Itanium, it is SO different from everything else that more than a quarter century of compiler refinement has to be thrown out and the work started from scratch, it will take quite a while before the software will catch up to the hardware, which is unfortunate for Intel because the EPIC architecture is very dependant on smart software.
      • b) gcc sucks

        I would disagree. GCC actually rules. It is fast enough to work quite well (afaik Linux can only be compiled on GCC and the performance of Linux is faster than commercial systems compiled with 'better' compilers), the third revision is looking extremely promising (even this early), and it is portable to many (most?) architectures! Additionally, as research into advanced compiler technology is conducted and applied to the program, it can't but help to get better in many ways.

        Then again if they stuck to C and not C with C++, Objective-C (we'll maybe keep Objective-C), Fortran, Java, and Ada
    • Don't blame them for playing both sides of the fence. They have to keep their options open. PA-RISC is dead and everyone knows it. What eventually replaces it is HP's future in enterprise scale computing.

      With these matters at stake who can blame them for not assuming Intel has the right answers. Intel, for all it's success, is a PeeCee and embedded CPU manufacturer. If Intel manages to crack the big iron market it will be a first for them.

      IBM would be more than happy to assume complete market dominance once again if it's PeeCee manufacturer competition fails. MIPS isn't dead yet, and Sun isn't about to let Intel ruin SPARC.
    • Re:HPs Strategy (Score:5, Insightful)

      by Syre ( 234917 ) on Monday January 20, 2003 @04:41PM (#5121287)
      Trillions (yes you read that correctly) of dollars per day move around the world on VMS-based money transfer systems (before you question this, think again. I have managed some of these money transfer systems. Over $1 trillion per day moved in and out of ONE bank I worked at several years ago).

      Trillions more are controlled internally by such systems. VMS systems also still power major mission-critical business processes at thousands of companies.

      You don't just drop a user base like that and say "ok, go convert overnight to a new processer architecture". These companies have long-term plans and are some of the biggest customers for large systems. They have already spent millions of dollars and years of effort converting from VAX to Alpha, and they aren't going to be willing or able to suddenly switch to Itanium.

      For those who said "just recompile", they are missing the point. It's not just the programs which need to work absolutely and perfectly, it's the OS, and VMS on Itanium doesn't even exist yet. And once it does, it has to be proven to work reliably. These systems have to have PERFECT uptime. Sure, they have hot standbys, etc. but switching over and back is typically a painful process. Remember: much of the code which runs the world is decades old.

      If HP doesn't want to lose billions of dollars worth of business, they won't be pulling the rug out from their VMS/Alpha customers any time soon, and the cancelling of the EV8 could very well be their undoing in this market. Unless they are able to come up with an absolutely reliable VMS port for Itanium and rock solid porting tools, this user base will migrate to some other platform (at great expense and effort) and it may very well be something other than HP.
      • Sure, they have hot standbys, etc. but switching over and back is typically a painful process.
        Um no. It depends upon the application and mixed cluster support for more than just migration. Where I have been working, we can switch from one Alpha to another inside half a minute. Most of the delay is due to lock remastering (the app uses a *lot* of locks).

        The app here may be over ten years old, but it has been continually updated.

        • Re:HPs Strategy (Score:4, Informative)

          by Syre ( 234917 ) on Tuesday January 21, 2003 @06:14AM (#5125724)
          I said typically.

          The fact that your particular place of work happens to have it figured out is no contradiction to the general case.

          And you're talking local switching. In banking operations, you have remote hot standby in case your datacenter burns down or something else really bad happens (both COs you're connected to die at once, for instance).

          With remote hot standby, switching and switching back is often (note the often) much more painful.

          In case you still don't get it, note that switching implies that one of your datacenters is DOWN and you are now on a completely separate system with separate disk drives, communications links, etc. Switching back means that you have to bring everything back up, sync it, and fail back again.

          Sure, it works. Is it fun? No. Is testing it and retesting it under every failure condition under a new OS port and processer architecture fun?

          Um no.
          • Our primary clusters are in two fire-proof and bomb proof rooms. A direct hit by an airliner or a major truck bomb could take it out but that is about all. No computer room has an exterior wall.

            Our remote cluster is far enough away that it is safe but remains close enough to participate in the main clusters (about 40Km).

            Our primary worry is RMS Journalling and the VMS Distributed lock manager, If these work, then failovers are a doddle.

            Note that when the company went to Alpha from VAX, Digital were extremely generous with testing facilities. The application supports two processor architectures with two executable directories left over from the VAX migration. As long as the lock manager performs well our app will quite happily fail over.

      • Back in my COBOL days I took some time getting used to just how conservative large financial institutions are. Even the most conservative mainstream software companies are raging cowboys in comparison.

        Even if you port and test everything, they're going to wait until there's a substantial track record of working reliably simply because no ever wants to find an obscure condition which incorrectly bills a million people - even a minor rounding error can be significant with billions of dollars floating around. They're going to do anything necessary to avoid having to prove the fault-tolerance system any of the thousands of transactions in a momentary outage from being dropped or (worse) misprocessed.

        The other factor is constraints - there are a surprising number of contracts, regulations, industry rules, etc. which spell out the exact environment something is going to run on. Getting changes approved can take absurd amounts of time. The change management process on this kind of large system will seem completely unreal.
    • Re:HPs Strategy (Score:3, Interesting)

      "Why didn't Intel just buy the Alpha architecture and continue it?"

      Easy, lets count on how much time and money both intel and HP invested in Itanium? 10 years and 5 billion dollars!

      Their VP's and stockbrokers demand a return on their investment and will get it one way or another. In the bussiness world their is no such thing as a "bad investment" sadly enough. They are very brutal to failure and will do everything to save face. Both CEO's of Intel and HP would be canned if they decided to not continue the itanium. Even though this might be the best approach in the long run.

      The itanium is a bloated overclocked piece of crap. Its an engineering disaster and the only reason it performs mediocrely well is because it is majorly overclocked with a one pound heat sink and a 500 watt fan that would blow away any case less then 50 pounds. Its true. Its a monster and nearly impossible to program for in assembly. This also makes it perform not to well under Linux since gcc is not very optimized for it.

      I agree that the alpha is a better chip and yes the EV7 is actually obsolete( intel canned the ev8). May it rest in peace. Stupid bussinessmen gota love em.

    • Re:HPs Strategy (Score:3, Interesting)

      by uncleFester ( 29998 )
      ooo, a dupe comment for a dupe story! [slashdot.org]

      marvel was already in the works before the HpaQ merger, and it would really make little sense to take a chip all the way to fab w/o at least running SOME of them to try and recoup some cost.

      Plus it will probably give Intel a good idea of which components of Marvel to rape for the next gen of the (t)Itanic.

      addendum: Dec/Compaq admins/users were also promised at least one more alpha for binary-compatible upgrades as a means to stretch past/current investment in systems while they figure out their next step (i.e. "oh peachy, alpha is dead.. what the fsck do we do now?") Had HPaQ reversed that decision I would bet the suddenly-abandoned Alpha users would cross HP systems of their list of potential replacement (myself, I was looking to switch to p-series IBM boxen).

      I was a very short-lived DecpaQ Tru64 admin, but have to admit I fell in lust for the OS and architechure. Our alphas ran superb for their age and the obscene obese demands our Oracle DBA inflicted upon them. Nary a whimper. I still think it's mildly criminal Compaq threw away the horsepower farm simply because they were too stupid to market the things properly.
  • by Anonymous Coward on Monday January 20, 2003 @02:37PM (#5120298)
    This all important benchmark seems to have been left out.
  • by nosferatu-man ( 13652 ) <spamdot@homonculus.net> on Monday January 20, 2003 @02:38PM (#5120302) Homepage
    ... at least on OpenMP type applications. Cribbed shamelessly from realworldtech.com:

    SPECOMP2001 results, base/peak:

    4 cpu:
    EV7/1150: 6027/6824
    I2/1000: 3762/4091

    8 cpu:
    EV7/1150: 10349/11929
    POWER4+/1450: 9458/ 9694
    PA8700+/875: 4375/ 4541

    16 cpu:
    EV7/1150: 17724/20637
    PA8700+/875: 7763/ 8788
    R14k/600: 7265/ 7726

    Note that this is not a pure CPU test (like SpecINT/FP), but rather a test of SMP performance. Looks like the tin-foil hat "Wait 'til EV8!" brigade might have been on to something ...

    'jfb
    • SpecOMP (link) (Score:4, Informative)

      by nosferatu-man ( 13652 ) <spamdot@homonculus.net> on Monday January 20, 2003 @03:13PM (#5120504) Homepage
      Info on SpecOMP [specbench.org], just in case anyone's interested. Also, here's a snippet from the FAQ:

      Q3: What components does SPEC OMP measure?
      A3: Since the benchmarks are designed to reflect applications requiring compute-intensive parallel processing, they measure performance of the computer's processors, memory architecture, operating system, and compiler. It is important to remember the contribution of the latter three components.

      'jfb
    • Its a pityfull shame its dieing. If they can get that sort of performance when the company is being screwed around then what kind of beast can they make in a stable environment.

      I, like many other computer engineers, worship the ground that alpha designers stood on. To imagine that they for a bit of a laugh as an aside project created the StrongARM seems silly.

    • sorry, nosferatu-man, but those marks are misinterp'd

      As Rob Young pointed out in his post [realworldtech.com]:

      "Not sure what you cobbled together but threads are your CPU counts. All the EV7 results are for 16 CPUs"-RY


      Tester Name System Name CPUs Threads Base Peak
      Compaq Computer Corp AlphaServer GS320 Model 32 64/731 16 16 5073 --
      Hewlett-Packard Comp AlphaServer GS1280 Model M16 16 4 6027 6824
      Hewlett-Packard Comp AlphaServer GS1280 Model M16 16 8 10349 11929
      Hewlett-Packard Comp AlphaServer GS1280 Model M16 16 16 17420 20066
      Hewlett-Packard Comp AlphaServer GS1280 Model M16 16 4 5482 6324
      Hewlett-Packard Comp AlphaServer GS1280 Model M16 16 8 10040 11547
      Hewlett-Packard Comp AlphaServer GS1280 Model M16 16 16 17724 20637

      Info from here [specbench.org].
  • by Peter La Casse ( 3992 ) on Monday January 20, 2003 @02:39PM (#5120311)
    Does anybody think that HP isn't going to phase out the Alpha? For some, that doesn't matter much, but I imagine that lots of people are going to be hesitant about buying into a system whose days are so obviously numbered.
    • I'll wait until the Beta comes out. *ducks*
    • Not to worry (Score:2, Informative)

      by ACNeal ( 595975 )
      It appears they have a program in place to cost effectivly move the Alpha customers to the new Itanium systems when they come out.

      They are calling it their Customer Assurance Initiative [hp.com]
    • Why is this a problem? I know people have code optimized for a given architecture but really the best way to write your code in the first place is to write it all in portable C or whatever and then add in platform-specific optimizations. If you switch platforms you can go back to the unoptimized code and reoptimize with inline assembler or what have you.

      The time you get problems is when you start depending on OS-specific services too heavily. Designing your program with portability in mind from the start doesn't add that much effort to the process and makes your life dramatically easier later because you can be platform agnostic, and just use whatever suits a particular job that day.

      • Some applications are very involved. They are not intentionally coded in a dependant way but to squeeze the last bit of performance out, you must use some architectural features, whether explicitly or depending upon their implementation in the underlying operating system. For example, VMS applications tend to use cluster services a lot to ensure high availability. The lock manager is so tuned that architecture moves can and will impact it which in turn impacts the applications (particularly databases).
  • Odd reporting... (Score:4, Insightful)

    by guido1 ( 108876 ) on Monday January 20, 2003 @02:39PM (#5120316)
    So first, the inquirer states that HP will be posting no perf. specs for the server until blah blah blah... (But in reading the article, it's "a guy who knows overheard someone say that they won't be posting...".)

    Later, it finds performance specs and posts them? (Without listing a source for those numbers...)

    Odd journalism to me... Sure, the Alpha sounds pretty good... But I'll be lame and wait for the official numbers...
  • Ahh the memories (Score:3, Interesting)

    by batboy78 ( 255178 ) on Monday January 20, 2003 @02:40PM (#5120322) Homepage
    I have such fond memories of my 21264 Alpha, its a shame that they are so expensive now though. I always wanted to get a quad-processor board and try to find oil or compile my kernel in 1 min.

    HP will probably make sure that these boards and chips are not accessible to the non-commercial Alhpa lovers. So I will have to wait 10 years to get a cheap one off of Ebay.

  • by Anonymous Coward on Monday January 20, 2003 @02:42PM (#5120333)
    Real nicly too....everyone who's demo'd one has drolled at it.
  • by Anonymous Coward
    Its an Alpha, but yet it uses RDRAM. Slashdotters not sure if they love it or hate it.
  • by rindeee ( 530084 ) on Monday January 20, 2003 @02:59PM (#5120444)
    "32-way systems will be available mid-2003, and 64-way systems near the end of 2003." A couple of things come to mind. 1. How will the 64 proc model compare to the new SGI Altix 3000? 2. Is anyone (now or planning to in the near future) scaling the Itanium2 up to that level? I have not heard mention of a 64 proc I2 production system, but then I haven't followed it very closely. Anyone have any info on this? Also on their web site "The next step forward in a long term future with HP". I would take this as an implication that they are planning on keeping the Alpha platform long-term (of course implying it doesn't make it so).
    • 64 Pro I2 - Why ? Itanium servers is foremost for Windows. Real operating systems supports Beowolf, so just do 8 8 cpu machines.
      • by rindeee ( 530084 ) on Monday January 20, 2003 @03:24PM (#5120600)
        Well, the first thing that jumps to mind is that a single "box" with 64 processors using partitioning is typcially faster (as is the case with the Altix using NUMA) and it is easier to manage (of course I say that having never touched either a 64proc box or a 8x8 cluster).
        • by nbvb ( 32836 ) on Monday January 20, 2003 @03:46PM (#5120860) Journal
          Yes, yes it is a lot easier to manage.

          And for the schmuck who said "Real operating systems supports Beowolf"... :
          a) It's Beowulf, not "beowolf". Check your literary history.
          b) Bullpoop. Beowulf's got nothing to do with the OS, and everything to do with the applications. You show me an Oracle that uses MPI or PVM.

          Of course! There's no need. Oracle already has OPS (Oracle parallel server). So yes, you can have an "8x8" cluster of Oracle nodes. Ever try to manage one of those? It's definitely a cluster ---- a cluster*uck!

          SMP is a beautiful thing. It's not exactly linearly scalable, but close. And the beautiful part is that if your app is multithreaded, it'll automagically take advantage of the SMP capabilities of the system -- no need to code to the MPI or PVM API's.

          Just for sheer "damn, that's cool" factor, think about this:
          A Solaris 8 CD will boot and install on a single-proc, 33mhz SPARCstation 10 from 1992 all the way through a 108-processor, 900mhz/each Sun Fire 15000.

          Now _THAT_'s scalable.

          --NBVB
      • by Anonymous Coward
        64 Pro I2 - Why ? Itanium servers is foremost for Windows. Real operating systems supports Beowolf, so just do 8 8 cpu machines.

        "foremost for Windows" ? When most benchmarks for Itanium2 systems are posted using HP-UX or Linux ?

        HP is pushing IPF systems as the systems you want if you want flexibility in running Windows, Linux or high-end Unix (read: not Linux 2.4 or 2.4++).

    • by Anonymous Coward
      Is anyone (now or planning to in the near future) scaling the Itanium2 up to that level?

      HP will introduce Superdome systems running Madison processors (Itanium2 shrink) this year (most likely scaling to 64way). Someone from HP also mentionned that they plan to put 2 Madison processors on a board, so we may see 128 way systems (with reduced bandwidth/proc) before Intel comes out with two-cores processors. Until then HP only sells up to 4 way systems. HP used to resell NEC's Azusa system (up to 16 Itanium (not Itanium2)), however it made no sense to buy one.

      an implication that they are planning on keeping the Alpha platform long-term

      You are reading too much in that sentence. Alpha systems are being phased out. For HP, the future of the high-end is Itanium only (phasing out Alpha and PA-RISC in the next 5 years). IIRC there should be one more iteration of Alpha processors (EV79?), then nothing new, just support.

    • Sorry, that should read "Is anyone ELSE" as SGI is using I2s in their system.
    • by Anonymous Coward
      HP has claimed that their SuperDome was designed to heterogenously support either PA-RISC or IA-64 cpu modules, in the same frame.

      I have some co-workers who were in Palo Alto and say they saw a running system alomost two years ago at HP HQ.

      HP's roadmap for ageas has been that Itanium based SuperDomes are on the way real soon. The supposed release for a 64-way Itanium 2 last I heard was Q102...so they have a couple of months to deliver or change the date again.
  • by Chocolate Teapot ( 639869 ) on Monday January 20, 2003 @03:00PM (#5120447) Homepage Journal
    This is a server system? A closer examination reveals that 'Hewlett Packard' is an anagram of 'whacked platter'. Better back up those hard drives now.
  • 2-4 processor setups (Score:4, Interesting)

    by Cheeze ( 12756 ) on Monday January 20, 2003 @03:04PM (#5120467) Homepage
    dollar for dollar, x86 offerings will be much lower in price and support costs in the 2-4 processor setups. I think HP should team up with a company like Apple or Sun and start offering processors on the alpha platform that run the other company's software. Can anyone say OSX on EV7?
    • by pmz ( 462998 ) on Monday January 20, 2003 @04:06PM (#5121044) Homepage
      dollar for dollar, x86 offerings will be much lower in price and support costs in the 2-4 processor setups.

      I'm not so sure about this anymore. I was very impressed recently when I saw the diagnostic output from a Sun workstation that had a failed component. The Sun workstation reported down to the chip where the system had failed (the information comes out of the serial port during POST). When time equals money, this sort of stuff is hard to beat.

      x86 boxes usually require hair-pulling trial-and-error troubleshooting that makes one feel terrible about the time wasted. Conversely, with the Sun box, the admin basically said "oh, that's it" and called the vendor.
      • or if you have a HA cluster of inexpensive boxes, just dump the faulty one & replace the component if obvious to find.
      • Totally. With IRIX you're in the same boat, with crash reports giving percentage odds as to which component has failed. Typically this ends up with a 90% rating for one thing, and nothing elsewhere. That's the sort of thing that requires neat well designed hardware.
    • Can anyone say OSX on EV7?

      I just did, but you'll have to take my word for it.

      Can anyone say "rhubarb Constantinople?"
    • Oh, man do I wish Apple had signed on with the Alpha processor instead of the PowerPC when they were looking to upgrade from the 68k. They went with PowerPC, I would guess, because it was made by Motorola, who had treated them so well with the 68k. If Apple had migrated to the Alpha instead of the PPC, their systems would now be absolutely incredible. Not to mention the fact that there would probably have been more money over the past several years to research the Alpha, and more demand for such. Too bad.
      • Nope, they would have never made laptops anymore if that were the case. Alphas are fast and powerful, but run hot as hell. You're not going to be able to stick one of those in a laptop or recording studio.

        Heck, people have been complaining about the noise on the MDD G4 systems since they came out!
        • That's a good point, but Apple has devised an incredible scheme of soundless cooling which would work in a recording studio (I'm surrounded right now by 3 Apple computers, and none of them are making the slightest peep. (2 iMacs and a Powerbook). I'm sure in the several years since they switched to PPC, they would have been able to figure out a way to cool their Alphas. (Maybe Macs would be the first consumer available system to use water cooling...)
    • OS X is so also extremely portable. The vpu on the G4 is really nice, and Apple is doing wise things like contributing GNU math libraries that take advantage of it. I realistically expect OS 10.3 to be much faster in comparison to 10.2, just as 10.2 is to 10.1 and the latter to 10.0. And, some day when it's time to mave on to a different architecture (or power up the G4, come on IBM and Apple).

  • by mnmn ( 145599 ) on Monday January 20, 2003 @03:18PM (#5120531) Homepage

    It would be nice to see HP sell Alpha as standalone processors and with a chipset offering, like in x86, for AT and ATX mobos. Custom Made-in-Taiwan parts will augument the system to produce very high power to cost ratios, and might allow the Alphas survival against the Itanium, UltraSparc, PowerPC and others.

    Has anyone seen the cheapest-ever duron+mobo combos from ECS where the processor is actually mounted without a holder, via solder onto the board to make the thing really cheap? I know I would buy an offering like that using Alpha. Sure I know stability and secure hardware are the main reasons people buy full servers in the first place, but not all applications demand stability and flexibility to match the power, and I havent seen offerings in this region outside of the Wintel arena.
    • I have to ask, why bother? AMD's x86-64 chips will be rolling out in 1-2 way for Athlon XP prices (supposedly) and 2-8 way for ... well, at least substantially less than itanium2. Alpha may be great but is it really worth the lack of support which will come your way? And a board with a soldered CPU, I wouldn't buy anything expensive (as any Alpha-based system will be) that was made like that.

      I can't see any reason to use anything other than Hammer in the low-end 64 bit market, unless you're trying to have your whole shop be binary compatible.

    • Something like what you describe would be very competitive with that new one from IBM, what's it called, the 907?

      Well, I hope your idea happens, but I doubt it - especially the part about cost.
    • by Best_Username_Ever ( 582302 ) on Monday January 20, 2003 @09:25PM (#5123629)
      There is absolutely no way HP will try and take on Intel or anyone else in the market for low-end single processor systems. For starters the Alpha costs a lot because it has been made with scalability in mind, it cant compete on price with an Intel chip. The size of Intel and the volumes of chips they produce means HP could not compete (seen AMD's P&L figures lately?). Micro$oft also pulled the plug on alpha support years ago, and windoze still drives the low end single processor market (despite all the hype surrounding Linux).

      Compaq were too scared of Intel to even remain in the high end market, where Intel are yet to make an impact. The competition is going to be fierce, it will be interesting to see if Sun and IBM can compete in the long term. Sun are already starting to look shaky, but at least they were willing to stay and fight. I think Intel will eventually push it's competitors out of the processor market, except maybe for a few niche products. The market is IMO a natural monopoly just waiting for one company to step up to the plate. The fact that Alpha is being killed just proves the point that superior technology counts for little.

      Alpha is dead, this is the last hurah in what was a very significant era. Great technology developed by brilliant technicians and killed off by incompetent managers.
    • Those ECS duron+motherboard combos are getting a bit leery. The latest versions are called "D1400+" processors but run at 950 MHz. I didn't see anything at AMD that announced that they were using performance ratings for the Duron.

      Since you can still get 800 MHz Durons for $24, don't bother with those combo boards even if they are using the better Morgan core.

      Kris
  • by evilviper ( 135110 ) on Monday January 20, 2003 @03:32PM (#5120711) Journal
    Just think... Most every task that isn't done fast enough today is due to floating point calculations, or memory bandwidth.

    Just imagine how quickly MPlayer/Mencoder could encode video on these new alphas... The specFP tests show the new Alphas better than double the performance over Sun, IBM, and almost double increase over older Alphas.

    You know... Something very new is going to need to come along before end users need more power than this for their home machines. Perhaps MPEG-5? Theora? Tarkin?
    • Sorry, mplayer/mencoder generally do not use fp-based codecs. (exceptions include wma1, wma2, ogg(can use int), mp3lib(can use mad or libavcodec (both int)) for example in libavcodec: [me@hidden libavcodec]$ cat *.c | grep -c ';' 20202 [me@hidden libavcodec]$ cat *.c | grep -c float 155 Most of those are in the native wma1 and wma2 (which are part of ffmpeg/libavcodec, eliminating that and the ac3 stuff (ac3*) and a62 brings it down to 89, none that I can determine in video codecs (didn't check all of them, though)
      • Surely you should have counted instances of "double" rather than "float"?
      • It's a bit hard to find just by greping the source. Since it's been designed mainly for i386, you will see some code done in assembly. In other cases, they have used some other workarounds specifically to avoid using floating point. Sure, it'll take some retooling, but MPlayer should work much faster on non-i386 platforms when modified to take advantage of floating point.

        In addition, I was just checking out Vorbis, and ``Tremor" (the int-only .ogg player) is still just a CVS snapshot... The current players and encoders use float.

        Not that it matters, the video is what takes so much time to encode. It's that this simple fact blows your credibility to hell.
  • But with the Opteron shipping in April they said "Aww, what's the point."

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Working...