64-bit: More than just the RAM

[darktiger]

Good article.

http://www.bit-tech.net/bits/2007/10/16/64-bit_more_than_just_the_ram/1

[six_storm]

Good article, good find. Thanks!

[l3ender]

Not a bad read, but in reality, the only major difference at this point in time is the RAM. Not too many programs have a full 64-bit support program, though this is getting better.

Though I love Vista x64, the only difference really worth mentioning (IMO) IS the RAM.

[svet-am]

Not a bad read, but in reality, the only major difference at this point in time is the RAM. Not too many programs have a full 64-bit support program, though this is getting better.

Though I love Vista x64, the only difference really worth mentioning (IMO) IS the RAM.

A big one I noticed that takes full use of x64 is 7Zip. the x64 edition unzips and zips much faster than the x32 build because it can process the encryption algorithm much more efficiently. This isn't a big deal on small archives, but I routinely deal with multi-hundred megabyte size archives on a regular basis.

[six_storm]

I would really like to see 64-bit become more common within the next year or so. I've got a copy of Vista Ultimate x64 sitting around but I really need a machine to really harness that potential first. I really just need another hard drive lol.

[RangerSVT]

Not a bad read, but in reality, the only major difference at this point in time is the RAM. Not too many programs have a full 64-bit support program, though this is getting better.

Though I love Vista x64, the only difference really worth mentioning (IMO) IS the RAM.

Maybe your difference, but most definitely not my difference.

[Moofasa~]

What I have always wanted to know is the "qword approach" just as efficient as a native 64-bit approach?

[Finn]

So in essence what that article said is that 64-bit is kinda nice and all in theory but in practise no-one except a selected group of graphic designers will see any benefit from moving into 64-bits for years to come. Considering all the potential for problems on driver level and the lack of software support it's not a very smart move at present time or near future.

Unless you run *nix that is.

[Scali2]

What I have always wanted to know is the "qword approach" just as efficient as a native 64-bit approach?

Yes.
I think the article there is not entirely correct.
The internals of the CPU don't actually handle anything other than qwords, just as 32-bit x86 since the Pentium Pro don't handle anything other than dwords internally
The smaller word sizes exist only in the x86 translation layer, not inside the actual arithmetic units, cache, load/store units etc (the internal registers, used in the register renaming file, are qword-only, and smaller data units will be extracted from these registers, or inserted. This may in some cases incur a 'partial register stall').
So for all intents and purposes, the internals of the x64 processors are identical to 'native' 64-bit processors. The main difference is in the x86 translation layer, but you already incurred that extra performance hit in the 32-bit processors. There's no additional penalty for 64-bit, so to say.

One of the biggest problems with 64-bit processors today is that 32-bit processors already were superscalar and had 64-bit databuses. This means that most of the theoretical gain from 64-bit computing was already implemented in 32-bit processors since the Pentium.
This leads to the irony that 64-bit code is sometimes slower than 32-bit code, because certain operations now require qwords, where 32-bit processors used dwords.

The most obvious example of this is a recursive function. On a 64-bit processor, every argument to that function is stored as a qword on the stack. On a 32-bit processor they are dwords. So obviously the 64-bit processor needs twice as much memory on the stack, and therefore also twice as much bandwidth. But the 32-bit processor already has a 64-bit databus, so it has the same bandwidth as the 64-bit processor, and the 32-bit processor can store two dwords on the stack in a single clockcycle because it is superscalar.
The workaround for this would be to implement your own 32-bit stack instead of using the default stack.
I've encountered this in my own code... it was slower when compiled to 64-bit... after analyzing the code, the stack turned out to be the culprit. After rewriting it to minimize bandwidth/memory usage in the recursive function, it ended up about 20% faster than the 32-bit version. Which makes sense... In theory 64-bit does give better performance because of the extra registers, which make it rely less on the stack and cache.
In practice, most 32-bit code probably has 'pitfalls' like these, and will be slower when just blindly recompiled to 64-bit (which we see with many 64-bit applications today, one of the saddest examples being Half Life 2 in 64-bit. In Lost Coast my average framerate drops from 160 to about 120 fps when comparing 32-bit to 64-bit). Developers will have to be educated in how to optimize their code for 64-bit.

[l3ender]

Maybe your difference, but most definitely not my difference.

Care to elaborate?

[Moofasa~]

One of the biggest problems with 64-bit processors today is that 32-bit processors already were superscalar and had 64-bit databuses.

So then why doesn't 64-bit processors have a 128-bit databus?