64-bit version of AA

[Zombie_Mod]

If I use the processor in 64 bit mode then I am able to memcpy() 64 bits at a time, instead of 2 32-bit reads. This is by far a better use of bandwidth.

Propably. I dont know much about the internals of the memory bus used by the 64bit athlons... But wouldn't such function be bottlenecked by the memory bus bandwidth before the cpu? (Assuming you're copying blocks big enough that they wont fit entirely in the cache)

Quote[/b] ]Also, as I said, the 64 bit CPU has extra registers, therefore the amount of writes to temporary storage for "local" variables will be reduced, improving performance considerably and reducing need for bandwidth.

If it improves performance considerably then why aren't the benchmarks considerably faster?

Quote[/b] ]C++ compilers use the stack for local variables but if you have more temporary registers to use then I would expect stack usage to decrease, wouldn't you?

Maybe, but more registers also means more things to store into the stack when doing a call.

(The boring stuff)

Well the memory bus bandwidth is always going to be an issue regardless of what architecture you are in; I still would expect the AMD64 to be faster though, just because you can move more data with a single instruction.

I mean, memcpy at its easiest on a 32 bit system is:

MOV ESI, OFFSET source
MOV EDI, OFFSET source
MOV ECX, count / 4
cpy:
MOV EAX,[ESI]
MOV [EDI],EAX
ADD ESI,4
ADD EDI,4
LOOP cpy

(Yeah, I know, I could use REPZ MOVSD too&#33

Surely if you are moving 8 bytes at a time the number of memory accesses for both instructions and data will be reduced, and the number of CPU cycles required in the loop above will be halved?

Sorry if you already knew this

As for benchmarks, well I don't know why they wouldn't be considerably faster; what benchmarks are we talking about? Windows 64 bit in general? Well as the 64 bit system is still new I dare say the drivers for the system are a bit poor at the moment.

(End of the boring stuff)

I still think a 64 bit version of AA would be a good idea though... do what ID has done and push the envelope, blow the competition out of the water... give us a game that will take advantage of the latest hardware.

You all know when Doom 4 comes out we'll all have to upgrade to 64 bit PCs anyway!!!

[snoops_213]

what would need to beed done to ArmA though to make it take full advantage and how long would it take to implement? Im sure 64bit is the way we will go in the future but for now why not release it as 32bit and with game2/3 make 64bit when more people are likly to own one, and seeing how Suma has already said there seems to be no advantage atm i say leave it 32bit.

Just my 2 cents.

Yay OFP:E gone "Gold" bring on ArmA news/details

[shinRaiden]

Woohoo! Geek fight! Reminds me of the old DEC Alpha Winnt software that could run x86 compiled code in emulation as fast as or faster than the best x86 machines for some time. Smartest move AMD ever made was sitting out in DEC's parking lot with a sack full of money for the dev's when Compaq gutted the place.

[Ozzzzzzy]

Quote[/b] ]Actually persistence of vision is about 72hz, although that varies from person to person. For me it's a bit higher, so 75hz is minimal for me. So FPS is a bit of a tricky item since FPS > refresh is pointless, and where refresh is > FPS some eyeball compenstation is present, especially on blurry LCD's which are persistent unlike CRT's.

Hey ShinRaiden I am curious about this subject. Where can i get more information on it and how did you find out what youre vision was and do you no if its consistent
or does it fluctuate

[Kegetys]

Well the memory bus bandwidth is always going to be an issue regardless of what architecture you are in; I still would expect the AMD64 to be faster though, just because you can move more data with a single instruction.

Shouldn't it also work the same by using the MMX registers? ie:

movq mm0, [esi]
movq [edi], mm0

I tried this quickly on my P4, and while it is about 4% faster than the 'mov' method, it is pretty much equal in speed with the 'rep movs' method that memcpy of MS Visual Studio uses...

Quote[/b] ]As for benchmarks, well I don't know why they wouldn't be considerably faster; what benchmarks are we talking about? Windows 64 bit in general? ***Well as the 64 bit system is still new I dare say the drivers for the system are a bit poor at the moment.

Pretty much all of them I have seen over time... In low level (Linux) benchmarks there are things where it is a bit slower, and some other things where it is a bit faster. In Windows gaming benchmarks there seems to be quite equal performance. I dont have any links to such benchmarks but google should find them...

Quote[/b] ]I still think a 64 bit version of AA would be a good idea though... ***do what ID has done and push the envelope, blow the competition out of the water... give us a game that will take advantage of the latest hardware.

If there is none or very little advantage of a 64bit version then it propably isn't worth the effort of maintaining and supporting two separate builds.

[shinRaiden]

Quote[/b] ]Actually persistence of vision is about 72hz, although that varies from person to person. For me it's a bit higher, so 75hz is minimal for me. So FPS is a bit of a tricky item since FPS > refresh is pointless, and where refresh is > FPS some eyeball compenstation is present, especially on blurry LCD's which are persistent unlike CRT's.

Hey ShinRaiden I am curious about this subject. Where can i get more information on it and how did you find out what youre vision was and do you no if its consistent
or does it fluctuate

http://en.wikipedia.org/wiki/Flicker_fusion_threshold
http://en.wikipedia.org/wiki/Persistence_of_vision

There's four parts of optical ergonomics at work here. First is flicker or refresh speed. This is the frequency that the display device is redrawn. Generally it is considered to be between 60 and 72 hz, though a variety of factors can impact the range and may move it higher for the individual.

Next is the scene redraw, your ingame FPS. This is how fast your CPU/GPU can generate and render a new 3D scene to be repeated each refresh cycle until the next scene is ready.

Third is the device optical properties. CRT's pump out vastly more more radiated light energy than LCD's, and eyestrain can be aggravated by ambient lighting, corrective lenses, diseases affected by intensity (like sinus crud making your eye muscles sore). LCD's, while not supporting as high of refresh rates and resolutions and sharpness, compensate with lower emmsions, device pixel persistence, and better color stability.

Fourth is scene luminosity and hue. 60hz on an all-black desktop is far more comfortable than 60hz on an all-white desktop, though subconciously the flicker will still affect you over a greater period of time.

[Zombie_Mod]

Well the memory bus bandwidth is always going to be an issue regardless of what architecture you are in; I still would expect the AMD64 to be faster though, just because you can move more data with a single instruction.

Shouldn't it also work the same by using the MMX registers? ie:

movq mm0, [esi]
movq [edi], mm0

I tried this quickly on my P4, and while it is about 4% faster than the 'mov' method, it is pretty much equal in speed with the 'rep movs' method that memcpy of MS Visual Studio uses...

Quote[/b] ]As for benchmarks, well I don't know why they wouldn't be considerably faster; what benchmarks are we talking about? Windows 64 bit in general? Well as the 64 bit system is still new I dare say the drivers for the system are a bit poor at the moment.

Pretty much all of them I have seen over time... In low level (Linux) benchmarks there are things where it is a bit slower, and some other things where it is a bit faster. In Windows gaming benchmarks there seems to be quite equal performance. I dont have any links to such benchmarks but google should find them...

Quote[/b] ]I still think a 64 bit version of AA would be a good idea though... do what ID has done and push the envelope, blow the competition out of the water... give us a game that will take advantage of the latest hardware.

If there is none or very little advantage of a 64bit version then it propably isn't worth the effort of maintaining and supporting two separate builds.

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.

In AMD64 it's just 1 read and 1 write.

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

I do agree that if it's not cost effective for BIS to produce 2 versions (32 and 64 bit) then they should not. But BIS are not a normal company, they have military contracts do they not, so I dare say they will already be developing for 64 bit PC systems now anyway, in order to model larger battlefields.

I really can't imagine how legacy 32 bit systems are going to handle the massive islands and DirectX 9 textures, increased numbers of unit groups, dynamic range sound that we are all clamouring for. With 32 bit systems, as you know, you have a 4GB address space per process (no 32 bit motherboards at the moment support it anyway) I bet this ceiling will be a problem soon (meaning, disk thrashing.)

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.

[Espectro]

ahh, MMX... first introduced in Amiga 1200 - under a different name

[Kegetys]

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.

[MattXR]

so whats this mean in simple terms?