Doom 3 performace as a 64-bit game (theoretically)

[Kenneth Porter]

--On Monday, October 24, 2005 11:26 PM -0500 Jonathan Berry 
<berryja at gmail.com> wrote:

> Perhaps this is what he meant.  Though, let's not forget a DDR memory
> interface is 64- or 128-bits wide.  I don't think it will take any
> longer to get a 64-bit pointer than a 32-bit one.  Right?  You get at
> least 64-bits per (FSB) cycle.  I still go back to it was an old quote
> and maybe doesn't apply anymore.  I cannot see any slight memory
> overhead outweighing the other benefits of x86_64.

The issue isn't the bus width but the total amount of instruction stream to 
be fetched. Let's say I issue an instruction that moves a byte from one 
absolute address to another. (I don't know if such an instruction exists, 
but this is just a theoretical example.) In 32 bits, this has to be at 
least 9 bytes long, one byte for the instruction and 4 for each of the 
pointers. The 64-bit equivalent is 1 + 8 + 8 = 17 bytes long.

Fortunately, this kind of instruction is unlikely to be common. There 
should be many processing instructions between pointer loads.

Does the AMD64 instruction set support 16- and 32-bit offset references for 
stack-based operations (eg. [BP + offset])? That's the more common case for 
referencing local variables.

Any kind of indirection will be more expensive, including virtual C++ 
method calls and general C++ object references, since one has to load a 
pointer before offsetting to data or the function to call.

OTOH, the greater number of registers means you don't have to "spill" one 
pointer to load another, so the actual cost of the longer pointers might be 
sufficiently mitigated by not needing to reload them as often.