First Benchmarks of AMD Hammer Prototype

porciletto writes "As seen on Ace's Hardware, this article features Quake 3 benchmarks comparing an 800 MHz ClawHammer sample to Athlon MPs at 800 MHz and 1667 MHz, as well as a Willamette Pentium 4 (256 KB L2, 400 MHz FSB) at 800 MHz and 1600 MHz. The benchmark results indicate a 40% performance increase over an Athlon MP for the ClawHammer. Additionally, the 800 MHz ClawHammer manages to tie (actually outperform by 1 FPS) the 1667 MHz Willamette Pentium 4."

Comments

Re:Intel has a Big Problem

[jtshaw]

Not to take the side of Intel... but as an Electrical Engineer with a good amount of interest in microprocessor design I have to say I like Intels move away from x86. X86 is definitly not even close to the best computer architecture out there.

It does make most sense for AMD to spend there time building a 64-bit x86 processor then it does a completely new architecture atm. But that doesn't mean we wouldn't all benifit greatly from dropping x86. Of course this can't be an overnight change, but it does need to happen.

Eventually you have to break backwards compatibility to move forward without making things ugly. x86 is old, it is overly complex, it is inefficient in many respects, it is time to say good bye. There is a reason the original designers only expected it to be a 3-5 year temporary solution.

Re:would be faster

[turgid]

AMD has effectively done that, if you've read any of the technical documents to see what they've done. The 64-bit mode has twice as many registers that are completely general-purpose (as opposed to the old CISC design of intel where one was a loop counter etc.) They've only implemented the simpler intructions in 64-bit effectively making it a 64-bit RISC. Since the K6, AMD processors have been superscalar RISC internally with a translation layer which breaks down complex x86 instructions into simpler RISC ones. It's still there for running legacy code, and completely transparent, i.e. it operates concurrently and with no performance penalty with the 64-bit instructions. The x86-32 registers are effectively just the top-right quarter of the x86-64 registers. Go and read AMD's docs. It's all there (and has been for the last 2 years).

Re:It would be more interesting if...

[Jugalator]

Ah, thanks ;)

Found this PDF document to be a very interesting document with tons of info about the Hammer. So intersting that I felt the need to post it here. :)

Regarding registers, it shows that not only has it got 2x "standard"/GPR registers that's 2x wide, but also 2x SSE/SSE2 128-bit registers.

So it seems to total in 16 * 128-bit registers, 16 * 64-bit registers (and 8 * 80-bit regs for floating point ops).

Yeah, and a widened program counter register too. :D

Not the best architecture

[dpilot]

Not to take either side...

But if Intel was going to supercede a messy architecture like X86, I wish they'd done something better than IA64. While the jury is still out on the merits of IA64, it has some of the marks of Internal Politics on it. It sounds like a VLIW camp inside Intel sold some management on a renamed version of the basic approach, and the project gathered Corporate Inertia.

At the same time, it doesn't sound as if all of the VLIW problems have been solved on the compiler side, so it's not clear that IA64 is doing any more than a clean, modern architecture cable of OOO execution could have done.

Out of the Hammer series, I'm reminded/hoping for the phenomenon described in "Soul of a New Machine", where they managed to clean and extend the old architecture at the same time. By the time they were done, the old architecture was an ugly wart on the side of a new clean one. The fear was the new being an uglier wart on the side of an already ugly one, and they avoided it.

I don't know enough about Hammer to know what the case is. I have the documents, but haven't made time to read them. I've also heard some rumblings that some of the performance improvements to IA64 involve de-purifying it's VLIW to pick up OOO techniques. I've heard that VLIW was an attempt to sidestep OOO because those prolems were feared, but in the meantime the industry has learned how to do OOO pretty well.

Intel should have bought Alpha years earlier ...

[BitMan]

As a fellow ECE, I'll give Intel a mark in the "innovative" column on IA-64. But the concepts of predication, EPIC and compiler-time optimizations we're NOT good enough to even make the new architecture competitive when not considering x86 compatibility. And Intel needs to be smacked for all those stupid extensions -- it's funny to see AMD accomodating them with less effort than Intel.

Alpha has always been the "64-bit RISC of RISCs" and they had binary translation techology c/o FX!32 so Linux/x86, NT/x86 and VMS/VAX apps could run on Linux/Alpha, NT/Alpha and VMS/Alpha, respectively. It was not only original, but using binary translation on the same OS, but different architecture, works far better for compatibility in software than general (any OS) architectural compatibility in hardware/microcode! With Alpha 364 at 0.13um would be kicking IA-64 butt. I mean, 3-year old Alpha 264 0.25um processors beat IA-64 at the same clock speeds!

Anyhoo, as a fellow EE/ECE, please read this post I made a few weeks ago and let me know what you think. It is entitled "How AMD and its partners are putting x86 back on the right track ... ". IA-64 was an ideal and novel concept, one that is not so good based in reality where good branch prediction is better than predication, and run-time optimization is just as important as compile-time. The Alpha 364 team predicted the "problems" with IA-64, which came true.