64-bit version of AA

[Espectro (DayZ) 0]

so whats this mean in simple terms?    

dont buy it

[Zombie_Mod 0]

Quote[/b] ]By using MMX you can load 64 bit quantities of data, for sure, but on the P4 you're still limited to a 32-bit bus, hence to copy 64 bits of data you have 2 individual reads and 2 individual writes of bits 0..31 and 32..63.

I'm quite sure this is incorrect. The P4, and everything else since Pentium Pro have a 64bit data bus so it should be a single read/write operation. Using the movq with MMX registers appears to be quite close to twice as fast as the 32bit mov when accessing data that is already in the cache, but anything that needs to access the system memory seems to be simply bottlenecked by the memory speed no matter what method you use to access it.

Quote[/b] ]I wouldn't use Visual Studio's assembler as a reference though, that's optimised for 386 processors, I noticed the code hasn't changed over the years since Visual C++ 4

How is assembler optimised for a certain processor (Other than what features it supports)? Its supposed to do exactly what I code (as it does, verified by disassembling the executable) and the MS Visual Studio assembler does support MMX, SSE and SSE2 instuctions, which I doubt existed when VS 4 was made...

Quote[/b] ]Just saying. It's a moot point anyway; as I said, next year Doom 4 will force everyone to upgrade, just as Doom 3 forced us to upgrade to new Radeon and Nvidia gfx cards.

It didn't force me to upgrade :P While the memory limit issue is valid (The 2GB limit of Windows especially), I dont think it would be very wise to make a game now or in the near future that would use that much memory and would require a 64bit processor - There simply wouldn't be enough customers that could even run your game. Doom 3 is a good example of an extacly opposite "policy" in my opinion, it ran playably even on a GF4MX. A 64bit platform does its job in what it is supposed to do, and that is allowing more memory to be used. But expecting massive performance increases is just not realistic in my opinion, and if you do not need the extra memory you do not need a 64bits.

For the MMX 64 bit data bus you state exists, can you point me to some documentation?

Secondly, if you look in C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt (or wherever your C runtime files are) you will see that the intrinsic assembly code for the runtime library hasn't changed since Visual C++ 4. There are no MMX instructions used there. Thats what I meant, the M$ runtime code hasn't changed for years.

If you hand code assembly, all well and good... good on ya.

If you thought I meant the actual compiler hadn't changed, well that's not what I meant

Also, assembler can be optimised for a certain processor.

e.g on some processors LOOP is slower than DEC CX; JNZ whereas on others it's faster.

See here for more info:

http://www.gamedev.net/reference/articles/article369.asp

[kegetys 2]

For the MMX 64 bit data bus you state exists, can you point me to some documentation?

Here, also check the architecture manuals from intel.com

Quote[/b] ]Also, assembler can be optimised for a certain processor.

The code obviously can, but not the compiler (Or assembler, it doesn't really "compile" anything). Or would you expect the "compiler" to change your loops to jnz's if it thinks that would be faster?

[suma 8]

Quote[/b] ]the intrinsic assembly code for the runtime library hasn't changed since Visual C++ 4. There are no MMX instructions used there.

There was no real reason to change basic functions like memcpy. While MMX or SSE implementation might be a little bit faster (only a little bit, because most cases will be mostly memory bus limited), it would have hardly any measurable effect on any real life applications.

In OFP I would estimate time spent in memory moving to 0.1 % at most - moving memory around is not very productive, and best optimization is usually not to copy/move it at all.

Reason why 64b native code will not be "per se" faster are similar - typical application is not performing vector / block operations very often (and that is also reason why it is quite hard to achive any significant perfmormance gain using SIMD/SSE instructions).

[-ZG-BUZZARD 0]

For now, all you need is a 64-bit Dual Core, but not for gaming. No, you need it to be able to address a suitable amount of RAM to keep Windows satisfied, and secondly to have a CPU to work with since the formerly usermode Windows Shell got jammed into  the formerly multitasked executive kernel back in NT4, ruining any hope of Windows being more than a brain dead crippled O$. So one core will just sit there locked up in Windows, while the other core dishes out all your other apps.

I've just read this so I just had to ask- in the end, it's not such a bad idea to have a multi-cored CPU because you'll always be running an OS on one core and can happily play away with full power of another core? That should be superior to any single-core CPU because a single-core CPU will be primarily busied with managing the OS's wants and desires even whilst you're playing your [32bit?] game or using your [32bit?] application... am I right or did I get something wrong here?  

Edit: And if that's right, god forbid me ever installing a 64-bit OS!!

[shinRaiden 0]

Exactly. Dual-core, regardless of bit-width, can optimize your system in that way. That is, provided you set your applications and windows to the different cores. That's regardless of whether you're on a 64-bit OS or 32-bit.

For 64-bit however, there happens to be some faster CPU's that happen to support wider addressing. Does the wider addressing make for faster operation? No, faster layouts make for faster processing. The promise of wider addressing for the time when such a need exists is a nice bonus on the side.