64-bit version of AA

[shinRaiden 0]

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.

Now seriously, does a better NIC chipset on the system bus instead of an older card in contention on the antiquainted and overloaded and bottlenecked PCI bus have anything to do with the addressing width of the CPU?

Ok, let's do say you got 8gb of ram. The only way you can touch it at all is with a processor that has 64-bit addressing. That's an advantage, but there's a nasty suprise too. Your addressing size doubled, so you have the same number of 64 bit memory blocks on an 8gb machine as you do with 32bit blocks on a 4gb machine, because the blocks are doubled in size.

So let's suppose that you have > 4(8)gb of ram, or your application uses 64bit data on a regular basis. Then you have a need and a use for a 64bit system.

Of course, your 32-bit apps are still stuck in 2gb memory spaces because Windows says so, unless you get the Enterprise Edition Windows Server 2003 that has a little tweak that can shift the Windows / App ratio from 2:2gb to 1:3gb.

Dual cores is something different entirely. IF you have a properly multithreaded that is ALSO signaled for multiple CPU syncronization, then you get significant performance scalability increases, even though you never get 200% or n00% due to overhead control. There was a thread either here or on the VBS forums where a user noted a significant decrease in performance in MP, as well as similar laggage in other games after upgrading to a dual-core CPU.

The problem appears to be that the applications do generate multiple threads at times, but do not adequately sync between them, instead assuming that certain data is going to be present at certain times. In dual-cores however, the threads are being bounced across the seperate cores and exec'ing out of sync. So the thread that's supposed to be waiting is instead finished, and the thread that was supposed to be finished before sending the data to the other one isn't there yet, and it's a miracle that it doesn't call down catastrophic racetracks and chaos. The solution by and far seems to be to lock the execution affinity to a single CPU core.

Now by this point it may sound like you got royally screwed by the marketing hype and gimmicks when your performance boost came via classic pipeline cleaning, mhz boosting, and moving the memory controller, instead of the 64bits or dual core. But that's where the perverted benefit of the dual core comes in. What you can do is lock you legacy application to a single core, and let Windows bloat along on the other cpu with all your background systray apps. That way you get as close to a fullly exclusive CPU for your game as possible. It's not nearly as cool as a properly coded app that can leverage both cores simultaniously and correctly, but is an interesting unintended positive side-effect.

[suma 8]

A few though on 64-b version of ArmA:

As many posters here already said, 64b native application is not necessarily better than a 32b one, and that is because 64 bit datatypes are not really usefull for general computing. While 16b precision is too low, 32b is already fine for most purposes (both integer and floating point). There are few cases where you might want to use 64b, like for high-precision timing or when addressing huge data sets in the memory (over 2 GB).

On the other hand, 64b platform does not automatically mean all your data will be 64b. By default only pointers are 64b, integers stay 32b unless you explicitely ask for "long long" ones. This means the data do not usually grow 2x. They will grow somewhat because of larger pointers, but pointers usually do not present most of your data.

Whether there is any real benefit in recompiling the ArmA for 64 platforms is yet to be seen. Besides of increased address size, those platforms usualy offer more registers, which can be quite beneficial for some computations. On the other hand, because of larger pointers, the memory footprint will somewhat grow. If the application is not really using 64b address space, it may even perform better in 32b version.

The answer to the original question "will there be 64b version of ArmA" is therefore this:

While this is still open, it is not very likely, as it currently does not seem 64b native version of the game would perform significantly better.

As evidenced even by the posters trying to defend 64b architecture, you get many performance benefits even when running current 32b applications on current 64b CPUs. Those benefits will certainly be there even if there is no native 64b version.

You may find some more reading on the Internet. Check links below or google for "64 bit real advantages" or similar words.

http://www.pcper.com/article.php?aid=76

Quote[/b] ]From my testing on both the 32-bit and 64-bit versions of Shadow Ops: Red Mercury, the claims made by both AMD and Atari regarding the enhancements to the AMD64 version come into question. What the 64-bit version does offer the gamer is an increased amount of visuals ... These did not show up in our 32-bit game testing and thus the 64-bit version of the game does have a bit of an advantage in this way. ...

However, the visual quality of the game I did not find to be any better on the 64-bit version of the game compared to the 32-bit. ...

These additional items that were added into the 64-bit game are mostly "fluff" -- they add a little bit more realism to the game -- but I see no reason why the same items could not have been added to the 32-bit version as well. There is certainly no technical reason for them to be omited. And while that "fluff" is by no means a bad thing, I would guess that it was added into the 64-bit only version either due to marketing desires from either Atari or AMD or purely for development time considerations.

http://arstechnica.com/cpu/03q1/x86-64/x86-64-2.html

Quote[/b] ]The take-home point here is that only applications that require and use 64-bit integers will see a performance increase on 64-bit hardware that is due solely to a 64-bit processor's wider registers and increased dynamic range. So there's no magical performance boost inherent in the move from 32 bits to 64 bits, as people are often led to think by journalists who write things like, "64-bit computers can processes twice as much data per clock cycle as their 32-bit counterparts."

http://compreviews.about.com/cs/cpus/a/aapr64bit.htm

Quote[/b] ]Much of the tasks that the average consumer does on the computer are more than adequately covered by the existing 32-bit architecture. Eventually, users will get to the point where the switch to 64-bit computing will make sense, but currently it does not. How many consumers out there will likely even have 4 gigabytes of memory in a computer system even in the next two years?

[Murmur2k 0]

Suma - may I ask, will ArmA at least be compatible (read working) on Windows x64?

[EiZei 0]

Suma - may I ask, will ArmA at least be compatible (read working) on Windows x64?

Uhh.. as compatible as any other 32bit programs running on windows xp 64?

I have not used any 64bit operating systems but I think the only things not supported are older device drivers and 16bit programs (read: DOS/Win 3.11).

[Murmur2k 0]

Yes it should work I know but sometimes developers (not saying BIS) make the installers so that it doesn't allow it to be installed on x64 for support reasons I guess. I just wondered if ArmA is ok for this - OFP works fine on x64 now so probably not a problem.

A problem is with pretty old games which don't recognise the windows version and abort install (obviously not a prob for ArmA).

[Espectro (DayZ) 0]

Yea, it would be stupid to stop supporting the 64 community.... Thats a way of stopping the future gamers of buying a game, lol

[Scrub 0]

Woah, the word from 'The Man'.  That pretty much sums up this thread..  (Sums.. get it?       .. yeah, ok, it was terrible)

[darkpeace 0]

I doubt a x64 version of Armed Assault will be released, at least in the medium term, due to the sheer lack of AMD64 and Intel EM64T systems running Windows® XP Professional x64 Edition or Windows® Vista*.

* A requirement for the extra features, registers, etc. Ala 64-bit mode. Otherwise your 64 bit processor is just running in 32 bit Protected Mode. (still with other nice features though :P)

A quick look over some statistics (albeit from another gaming company) reflects this:

http://www.steampowered.com/status/survey.html

OFP2 (or ArmA 2, whatever it gets named) has a release date when the mass consumer will likely be transitioning to 64 bit platforms (including Operation System, unlike from 2003 - today).

[Murmur2k 0]

Looking at that survey it seems not to take into account the number of processors with 64bit extensions.

[shinRaiden 0]

The problem with installers has been that a common vendor-licensed installer that was actually only a 16-bit app. NSIS is just as flexible if not more so, and if the developer needs to add a funky app or dll to the mix it can do that too.

[darkpeace 0]

Looking at that survey it seems not to take into account the number of processors with 64bit extensions.

Yes, but it does report the version of Windows people are running, and provide enough information to figure out who has Athlon 64's, even if they ain't running WinXP x64 :P.

[Zombie_Mod 0]

You wont get performance gains from moving to 64bit addressing, quite the opposite since the instructions will then use double the cache and memory bandwidth. What you get is the ability to address more than 4GB of memory and thats it. (Well, there propably are some performance gains when handling 64bit integers but its unlikely those will be used in any game in such amounts that you would notice a major performance difference). The AMD 64bit extensions do add some new registers to the CPU which can -when properly utilised- give performance benefits but I doubt they will do much other than bring the performance back to the "32bit" level, at least yet when the compilers aren't matured enough.

The most ridiculous thing about the issue is the idiotic marketing they have going on with the "improved features" that supposedly come from using 64bit processors which are used to fool the general public.

I have a AMD FX-57 with Dual 7800GTX's and on HL2..

I wasn't aware that a 64bit build of Half-Life 2 was available?

LOL,

I remember this chat 10 about years ago when MMX came out - "no-one will use it for years"

1. We've had 64 bit registers (well, OK, 80-bit) for years already. MMX anyone?

2. Secondly, Kegetys, are you trying to say one MOV QWORD is worse than 2 MOV DWORDs? I don't think so. It's only an extra byte for the 64 bit instructions, I don't know where you get "double the cache and memory instructions", unless of course you are including the 64 bit data too - but that's the whole point of the extra bandwidth!!!!

Show me an example.

Also, with the new 64 bit processors you get more registers, not just 64 bit versions of AX,BX,CX etc etc... as far as I am concerned, a 64 bit version of OFP, written with a decent compiler (e.g. GCC) would blow any 32 bit system out of the water.

Just one thing though - you really need 2Gb of memory for AMD64.

3. Compilers aren't matured enough? I'm interested in this. What compiler do you use?

Cheers,

Scott.

[kegetys 2]

I remember this chat 10 about years ago when MMX came out - "no-one will use it for years"

1. We've had 64 bit registers (well, OK, 80-bit) for years already. MMX anyone?

And your point was? And there have been 80bit registers in x86 processors much earlier than MMX, ever since the first x87 math co-processor. And MMX's largest mistake was that it uses those same registers.

Quote[/b] ]2. Secondly, Kegetys, are you trying to say one MOV QWORD is worse than 2 MOV DWORDs?

I never said such things

Quote[/b] ]It's only an extra byte for the 64 bit instructions, I don't know where you get "double  the cache and memory instructions", unless of course you are including the 64 bit data too - but that's the whole point of the extra bandwidth!!!!

And thats exactly my point - When you use the processor in 32bit mode all that extra bandwidth and cache is giving you better performance. And that advantage will be lost when you use 64bit code. True, not everything will grow, but for example all instructions that use the now-64bit stack will use twice the bandwidth.

Quote[/b] ]Just one thing though - you really need 2Gb of memory for AMD64.

2 gigabits? :P

Quote[/b] ]3. Compilers aren't matured enough? I'm interested in this. What compiler do you use?

I use many compilers. The point was that the x86-64 is a new architecture (or an extension) and compilers aren't propably capable of taking full advantage of the new features yet - Especially GCC which has never been the best in terms of optimizing code.

[Zombie_Mod 0]

I remember this chat 10 about years ago when MMX came out - "no-one will use it for years"

1. We've had 64 bit registers (well, OK, 80-bit) for years already. MMX anyone?

And your point was? And there have been 80bit registers in x86 processors much earlier than MMX, ever since the first x87 math co-processor. And MMX's largest mistake was that it uses those same registers.

Quote[/b] ]2. Secondly, Kegetys, are you trying to say one MOV QWORD is worse than 2 MOV DWORDs?

I never said such things

Quote[/b] ]It's only an extra byte for the 64 bit instructions, I don't know where you get "double the cache and memory instructions", unless of course you are including the 64 bit data too - but that's the whole point of the extra bandwidth!!!!

And thats exactly my point - When you use the processor in 32bit mode all that extra bandwidth and cache is giving you better performance. And that advantage will be lost when you use 64bit code. True, not everything will grow, but for example all instructions that use the now-64bit stack will use twice the bandwidth.

Quote[/b] ]Just one thing though - you really need 2Gb of memory for AMD64.

2 gigabits? :P

Quote[/b] ]3. Compilers aren't matured enough? I'm interested in this. What compiler do you use?

I use many compilers. The point was that the x86-64 is a new architecture (or an extension) and compilers aren't propably capable of taking full advantage of the new features yet - Especially GCC which has never been the best in terms of optimizing code.

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.

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.

And how can you say that a 64 bit stack will use 2x the bandwidth? That depends what is pushed on it. 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?

[kegetys 2]

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.

[Zombie_Mod 0]

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!

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 75]

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 0]

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 0]

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 2]

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 0]

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 0]

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 (DayZ) 0]

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

[kegetys 2]

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 9]

so whats this mean in simple terms?