Slashdot Mirror


Alpha 21364 EV7 Specs Released

Jon Carroll writes " HP has revealed their Alpha roadmap today at RDF and the schedule goes as previously planned. Alpha 21364 (EV7) is based on 0.18 micron to be shipped by this year end and EV79 based on 0.13 micron SOI will be up next. EV7 will be at 1.2Ghz while EV79 will be at 1.6Ghz. The Alpha 21364 EV7 chip will have 152M transistors, 1.75MB integrated on-die L2 cache, 32GB/s of network bandwidth, integrated RDRAM memory controller with 8 channels up to 12.8GB/s of memory bandwidth. "

8 of 174 comments (clear)

  1. alpha still lives? by Indy1 · · Score: 3, Interesting

    Wait, i am confused here. I thought Dec was bought out by Compaq, which then butchered Dec and their Alpha technology to the point that Compaq finally sold off what remained of the Alpha to Intel (and a bunch of former Alpha engineers also went to AMD if memory serves correctly). Can any one clarify what really happened to Alpha ? I hope that Alpha sticks around, as i feel its a good archtecture (forgive spelling) compared to the x86 stuff.

    --
    Lawyers, MBA's, RIAA? A jedi fears not these things!
  2. Re:Too little to late by susehat · · Score: 1, Interesting

    Don't forget that HP killed PA-RISC when they went to do Itanium. The Alpha is very cool. It really doesn't need to be killed off, and HP saw this. Besides, Itanium is lame, it has bad press behind it, and is is also a sitting duck. So, the best to the Alpha, since it seems that HP may want to get off the Intel Bandwagon.

  3. alphas and optimisation by Zurk · · Score: 5, Interesting

    just a short comment on how good the alpha high performance math libraries really are (and the alpha engineers -- may alpha rest in peace).
    I was writing code for a simple matrix transform using the algorithm as follows :
    for (a=0;a100;a++){for(b=0;b100;b++){
    txarray[a][b]=o ldarray[b][a];}}
    using the alpha libraries to do the transform instead rated me a 10x boost in speed.
    this was weird as i didnt see how the above algorithm could be optimized...tearing apart the assembly i saw :
    for (a1=0;a1100;a1=a1+10){for b1..{for(a=0;a10;a++){for(b...

    evidently they had optimised it so that reads and writes would occur from closely spaced regions of memory and less time would be spent writing.
    result ? a 10x boost on a simple algorithm and a neat hack at the same time.
    just an example of how awesome the engineering of the alpha wa

  4. Re:nice 64bit by Anonymous Coward · · Score: 1, Interesting

    Wait till you see what IA64-2 (Itanium 2) can do for FPU ops its just plain frightening. I'm talking 1.3K+ specfpu2000 score. From what a rep from a major OEM mentioned to me, IA64-3 (Madison) should double that.

    The really interesting thing is the parallels between IA64 and Alpha, that they both sucked hard in thier early varients. It is a little known fact that Alpha 21064 cost more than all other 64bit CPU's at the time and performed far worse.

    Oh I should finish off by mentioning that the current IA64 tools for linux suck donkey balls in the performance stakes hopefully this is one area where serious optimisation will be made.

  5. Re:nice 64bit by ToLu+the+Happy+Furby · · Score: 5, Interesting

    I bet that it could cane IA64 in the specInt but the real test would be floating point and to do IEEE754 properly you need 64 bit otherwise you end up emulating it

    x86 processors have had 64-bit floating point registers (actually 80-bit) for as long as they have done native floating point. x86 does not have 64-bit integer registers; this has nothing to do with floating point.

    The reason x86 has traditionally sucked at floating point is because the x87 floating point ISA only allows for a stack of 8 fp registers, instead of a flat set of 32 registers like most RISC architectures. This has been worked around to some degree in current x86 processors through the use of a flat virtual register set and good compilers, although there is only so much a compiler can do when it is limited to 8 target registers. Nowadays the continued leadership in SPECfp by 64-bit RISC chips is mostly due to higher memory bandwidth and particularly large L2/L3 caches which help a great deal with certain SPECfp subtests.

    While not quite as high as its world-beating SPECint scores, the P4's SPECfp scores are still damn good, and would be even better if Intel would officially support PC1066 RDRAM (the current scores on spec.org are PC800 only). Put another way, they will be even better when Intel releases their dual-channel DDR chipset in a few months.

    That said, EV7 will clearly have the SPECfp score to beat for quite some time. (Probably SPECint as well.) And Itanium2's SPECfp scores are reported to vault it well ahead of the also impressive Power4. But, again, this is all to do with higher DRAM bandwidth and larger caches, not with any inherent limitations of x86 for performing double-precision fp.

  6. GOD BLESS THE ALPHA! by Anonymous Coward · · Score: 1, Interesting
    AlphaServer 1200 and 164/LX user for several years.

    Once again, capitalism destroys superior technology, as the DECHPaq behemoth kills off all its own engineering masterpieces to appease Intel.

    Long live Alpha, long live Alpha/x86 binary translation technology, long live PA-RISC, long live HP instrumentation and calculators. Long live control by the competent, rather than the short term profit-minded!

    May Fiorina and Cappellas be given the softest of pillows to relieve their nightmares of guilt.

    4th July? Why are we celebrating independence from a nation now no less free than our own?

  7. Re:I remeber when by puto · · Score: 2, Interesting

    Alphas were running at 500 megahertz at the time the P60,90 were out.

    I remember becayse I almost bought one with the special version of NT for the Alpha. They only cost a small amount more and ran like scalded dogs.

    The only problem was that there was very little peripheral support and huge driver issues. But most NT stuff ran on them and ran real fast.

    AMD is the bastard child of the Alpha.

    Puto

    --
    The Revolution Will Not Be Televised
  8. The Hammer is NOT a good thing... by sl3xd · · Score: 2, Interesting

    While I prefer AMD processors over Intel's, and I have an x86-PC, as I understand the situation, the Hammer is not a good thing in any way. My understanding being that the Hammer is simply an extension of the x86 architecture from 32 to 64 bits. (in a remarkably similar fashion to how the 80386 was a 32-bit extension to the 80286/8086, which was a 16-bit extension to the 8085, 8080, & 8008. I'm not sure if the 8008 was an 8-bit extension of the 4004 or not; the 4004 was a 4-bit processor, and is considered to be the world's first microprocessor.)

    So the x86 architecture/instruction set still has a great deal of commonality with the Altairs running CP/M.

    The 'x86' architecture was only intended to be used for a few years. IBM first extended it from the Altair (8085, 64k) to the PC (8086/8, 1M). The popularity of the PC lead to the decision to extend the PC to the AT (80286, 16M). After that, IBM decided that the architecture needed replacement and then tried to kill it. IBM created an entirely new, superior architecture, complete with a new, superior OS. (The PS/2 and OS/2).

    This failed miserably. (Not in small part to the fact it was a 'closed' architecture-- just like Macintosh)

    Instead most of the world chose to stay with the 'x86' architecture (and the more economical clones), maintain backwards compatibility, and deal with its limitations. (I won't say flaws, because the original architecture was never meant to be extended this far to begin with. Of course, that was back with the 8080 and 8085, 64k (max) memory, the Altair, and CP/M.

    And now, the x86 architecture is one extension upon another, finally arriving at the monstrosity we know today.

    The Hammer (and Intel's 64-bit extension to the Pentium... NOT the Itanium) will be yet another generation of an architecture originally intended to handle no more than 64k of memory.

    It's sick; the best comparison I can think of is if the 'x86' architecture is compared to bare hands, the only tools we have are gloved hands with speed/power assist. No wheel, no lever -- just hands.

    The sooner we kill the x86 architecture, the better. It was ancient 15 years ago. Humanity gave up horses and slaves in favor of automobiles and machinery. We can give up the old x86 architecture for something better. Maintaining it is inhumane.

    But getting Intel, AMD, and others to cooperate (and share valuable, patented technologies with each other) is like asking Microsoft to GPL the source for Windows.

    --
    -- Sometimes you have to turn the lights off in order to see.