If I Had a Hammer

adpowers writes: "Anandtech is running an article about their preview of AMD's Hammer. They had one machine running 32-bit Windows and the other running 64-bit Linux. The Linux machine had a 32 bit program and an identical program that was compiled for 64-bit processor support. Both processors were less than 30 days old and running without any crashes, but they weren't at full speed." We did one Hammer story a day or two ago, but there have been several more posted since then (wild guess: the NDA expired). Tom's Hardware has a story, so does Gamespot.

Comments

Re:Two transition periods?

[XBL]

Umm, first of all it's hard enough to engineer a 64-bit CPU with related components. Then there is the manufactoring details, etc, etc. From that standpoint, it's not economical try to to do a 128 bit CPU now.

Second, there is no point in 128 bit for software right now. We are going to have a hard time even writing software that even requires a 64 bit processor. If we were stuck on 32 bit processors for another 5 years (yet with increasing speed), I really doubt that we would be much futher behind.

I am no expert, but I can't even begin to see the need for 128 bit processors right now. It's better to focus on making the current designs faster.

Re:Two transition periods?

[ToLu the Happy Furby]

64 bits should be enough for anyone.

No really, I mean it.

Clever, Ed. For those who don't get it, he's quite right: 64 bits *will* be enough for anyone.

For those still stuck in mid-90's video game wars, "bit-edness" in the real world refers (technically) to the size of your general purpose integer registers, which, for most intents and purposes, refers to how many memory addresses you can easily and quickly address. 32 bit addressing tops out at 4GB, a value which is often too small for e.g. large databases, which thus tend to live on 64-bit big iron machines. (MS has a hack to give x86 processes access to 36 bits of space, but it requires OS intervention.)

64 bits, on the other hand, works out to 16 billion GB. (That's 16 exobytes IIRC.) For reference, that's roughly 40 times as much memory capacity as there currently is DRAM produced (of all types, for all markets) worldwide in a year, at this January's rate.

I don't have the figures on hand for hard drive production, but I would guess as a first approximation that 16 billion GB is not quite equal to the total number of bits of digital storage of all kinds manufactured throughout computing history up until today. (I'd guess it's too small by a factor of 3 or so.)

In other words, it's quite a lot. Presumably computing will have run into some very different paradigm (wherein the bit-edness of the "CPU" is no longer an applicable term) before any computer has a use for >64 bit addressing.

(FWIW, today's 64-bit processors don't offer all 64 bits of data addressing yet, because no one has a need for more than 40-something, so that's what they offer.)

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[tempmpi]

There's a lot of difference between 32 bit optimized code compiled for 64 Bit, and code written and optimized for 64 bit and compiled for 64 bit.

That might be true if the only thing that changed were the register,adress space and ALU size, but AMD also removed many flaws of the x86 instruction set. x86 cpus got only 7 registers (EAX,EBX,ECX,EDX,ESI,EDI,EBP) for general purpose use. Other CPUs have much more registers, the lack of registers makes it very hard for compilers or assembler programmers to write efficient code for multiscalar cpus. AMD added more registers. AMD also made a more efficient fpu. You can really get a nice performance boost from these changes with just a rebuild of your software.

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform. Without that, the application speeds can't be compared, even though the base code and output is the same.

That isn't true, almost all programms, even games, are now programmed in C(++).(Or something like Java or Perl, but these programms doesn't matter here) The compiler can really use the extra registers/better fpus without any aid from the programmer(OK, maybe a compiler switch). Things like using the "register" keyword in C isn't really needed as good C compilers are better than most programmers at choosing which variables to keep in registers.

You also compared the transition from x86 to x86-64 to the transition for PSX to PS2. That is also something very different. The PS2 is hard to code because the design of the graphic subsystem and vector cpus make it very fast on the one hand but also very hard to use the full potential. The PS2 CPUs also hard to use because the caches are too small.

Put it in perspective....why don't 16 bit games re-compiled for 32 bit give a "major" performance boost...unless optimised code is included...??

When the 386 was introduces things like games were coded in assembler, at least the performance critical parts. Something that is coded in assembler can't be recompiled. Now even games are coded in high level languages.