64-bit version of AA

[Ozzzzzzy]

Is there any plans on making a 64-bit version of AA

[colossus]

I don't know much about how the 64-bit system works, but I
guess ArmA will support 64-bit CPUs if it's possible to do that
on one single version of the game.

But nothing is known yet, so there isn't much point in asking
anything about the game. http://forums.bistudio.com/oldsmileys/confused_o.gif

[Uziyahu--IDF]

I'm sure he was addressing the question to those who do know. If the devs don't know...

[shinRaiden]

Why? No, seriously, what benefit does 64-Bit addressing add to games functionality? Hmm? It's an honest question, and I've yet to hear any useful or coherent answer other than larger scale precision located maps, or extended bits for embedded GPU commands into next-gen image formats.

What I've heard little or no discussion on is what this is going to do to net traffic. Are you going to just double your packet size by shifting all your data formats from 32bit to 64bit? That will also halve your sync rate on the same bandwidth. Packet fragmentation lag? What about upstream routing? Trunk ATM encapsulation? ATM cells are fixed size, and EA's whining can't hold a candle to real enterprise big-iron infrastructure.

[Ozzzzzzy]

I got this from the AMD website - With an AMD64 processor and the new Windows® XP Pro x64 operating system, higher frame rates, enhanced textures, longer view distances, and more objects with real-time physics

[Commando84]

My uncle has a amd 64 processor and he tells me that he gets much better net speed in unreal tournament 2004.
he said he got like 14 or more in ping and now he get from 6-12 or something like that. he says its a big difference wehn playing games http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[EiZei]

I got this from the AMD website - With an AMD64 processor and the new Windows® XP Pro x64 operating system, higher frame rates, enhanced textures, longer view distances, and more objects with real-time physics
Want to buy a bridge?

[SGT. Hurley]

Want to buy a bridge?
Mate - WTF?

He's right, the 64-Bit CPU's do boost your framerate on games that allow it, I have a AMD FX-57 with Dual 7800GTX's and on HL2, A had a 2800+ and my frame rate was 150, but with my 64Bit CPU (fx-57) it bumped up to 170FPS, this came with greater detail and more viewing distances, this was without changing the video settings...

So don't flame someone is who perfectly corrected just because you know jack s**t.

Hopefully ArA is 64bit supported...

[EiZei]

Well.. must be some damn advanced addressing if it makes textures look better.


Quote[/b] ]
He's right, the 64-Bit CPU's do boost your framerate on games that allow it, I have a AMD FX-57 with Dual 7800GTX's and on HL2, my frame rate was 150, with my 64Bit CPU (fx-57) it bumped up to 170FPS, this came with greater detail and more viewing distances, this was without changing the video settings...

Uhh.. what? You say that your 64bit FX-57 could do 170FPS in HL2 as opposed to your 64bit FX-57 could do 150FPS in HL2? http://forums.bistudio.com/oldsmileys/huh.gif


Quote[/b] ]
So don't flame someone is who perfectly corrected just because you know jack s**t.
You do have some strange ideas about flaming.

[meyamoti]

20 extra fps? I fail to see a real point in that,why does anyone even need 150 fps,after 20-30 its pretty much the same.

[Placebo]

So don't flame someone is who perfectly corrected just because you know jack s**t.
His comment wasn't flaming, yours pretty much was, please refrain http://forums.bistudio.com/oldsmileys/smile_o.gif

[SGT. Hurley]

'Want to buy a bridge'??

What the hell is that? Not flaming? Just being an idiot?

Posted by EiZei: Uhh.. what? You say that your 64bit FX-57 could do 170FPS in HL2 as opposed to your 64bit FX-57 could do 150FPS in HL2?

I used my old Socket A 2800+ and got 150FPS, put in my FX-57 and got 170FPS (my bad..)

[Heatseeker]

I used my old Socket A 2800+ and got 150FPS, put in my FX-57 and got 170FPS (my bad..)
It is well known that 64bit CPU's boost performance in games considerably regardless of the applications being 32 or 64 bit but are you using XP64 bit edition and is there a 64 bit HL2 edition, patch or whatever? I know they released a Far Cry one. Seems like you just got a performance boost because of the uber CPU regardless of the app being 64 or not to me http://forums.bistudio.com/oldsmileys/confused_o.gif .

[Kegetys]

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?

[SGT. Hurley]

I wasn't aware that a 64bit build of Half-Life 2 was available?
Maybe it was like Heatseeker said, I just upgraded to a l33t CPU thats why my graphics FPS went up.. http://forums.bistudio.com/oldsmileys/wink_o.gif

[EiZei]

Posted by EiZei: Uhh.. what? You say that your 64bit FX-57 could do 170FPS in HL2 as opposed to your 64bit FX-57 could do 150FPS in HL2?

I used my old Socket A 2800+ and got 150FPS, put in my FX-57 and got 170FPS (my bad..)
So the twice as large L2 cache, improved instruction sets, general architecture improvements (Socket-A vs. 939), 250MHz FSB, and extra 800MHz had nothing to do with that? http://forums.bistudio.com/oldsmileys/huh.gif
Do you even know what that 64bit feature means actually?

Quote[/b] ]
'Want to buy a bridge'??

What the hell is that? Not flaming? Just being an idiot?

You certainly are easily offended for somebody that keeps calling others idiots.

[Berghoff]

I've tried some 64bit versions of apps (Windows XP 64, Farcry) and I don't notice anything different :P only thing different is that a 64bit 3000+ cpu is faster than a regular 3000+ cpu.

[Heatseeker]

FX57 (http://www.guru3d.com/article/processor/249/7/) Its a expensive and powerfull CPU and seems to boost performance quite a bit in regular 32bit apps, i think a 64bit ARMA edition would be a waste of developing time considering they made real virtuality engine run well on a crappy xbox http://forums.bistudio.com/oldsmileys/biggrin_o.gif .

[Dwarden]

dualcore (multithreading) support will be nice too lol http://forums.bistudio.com/oldsmileys/smile_o.gif

imagine AMD x2 5000+ http://forums.bistudio.com/oldsmileys/smile_o.gif))

ok ok i know OFPR / ArmAs was single thread coded so this is prolly impossible to happen ...

maybe with next gen game ...

[Scrub]

Yeah, real time Tactical AI, Strategic AI, Sound engine, and database on one CPU; Graphics, physics, and interface on the other. Munch those numbers.. http://forums.bistudio.com/oldsmileys/thumbs-up.gif

[shinRaiden]

Native 64-bit CPU's do NOTHING for your gameplay unless your data is 64-bits.

1) On the AMD64 platform, the memory controller was moved to the CPU. NOTHING TO DO WITH 64-BITS.

2) On the AMD64 platform, hypertransport was introduced to clean out a lot of the crap on the bus interfaces. NOTHING TO DO WITH 64-BITS.

3) On the AMD64 platform, local CPU cache was increased. NOTHING TO DO WITH 64-BITS, rather, there's the risk of only the same amount of cache slots due to the doubled buffers.

4) On the AMD64 platform, PCI-Express interface buses are becoming more prevelent, reducing the strangling bottlenecks for the GPU and system devices. NOTHING TO DO WITH 64-BITS.

5) On the AMD64 platform, reduced component trace sizes create shorter paths for 32-bit operations. NOTHING TO DO WITH 64-BITS.

6) On the AMD64 platform, technological design improvements to instruction logic flow have decreased 32-bit operation pipeline time. NOTHING TO DO WITH 64-BITS.

7) On the AMD64 platform, increased CPU processing cycle times lead to decreased operation times, regardless of addressing length. NOTHING TO DO WITH 64-BITS.

Btw, AMD just announced huge quarterly profits. Suprised? I'm not.

@Eizei...

Was that the North Bridge, the South Bridge, or ... the Brooklyn? http://forums.bistudio.com/oldsmileys/wink_o.gif

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.

[Scrub]

......


Are you actually trying to tell me that all the other processor of a dual core system can possibly do is babysit the OS? ***Really?

Hmm, then all the multi threadded apps, 3dsmax and NI's TestStand analysis and validation software (games or not) that execute amazingly fast on my workstation, compared to the single proc I use to have has nothing to do with the sharing on the dual cores? ***So the high speed cam input that is on one thread on core 1 (with the OS) and the 23 inputs (multiple threads) from the sensor suite on the other core didn't increase my accuracy, nor allow me to run the realtime tests 30% faster? (Could do quite a bit more, but we were already running the system at 125% of design ***http://forums.bistudio.com/oldsmileys/tounge2.gif ) ***So then exactly what was going on, from p4 3.6 to AMD 3800 x2 same NI DIO card (PCI)? ***Doesn't add up. ***Multi threaded apps allow them to do more work, or (if the string of instructions or tasks can be split and rejoined) work faster. ***That's my uneducated understanding of it.
Edit: If you care to, please explain. The only reason I'm being so hard-headed about this, is because I'd like to support the suggestion (if it's factual) that BIS look at multithreading (sorry, This is OT, and should be in NG2 forum won't say more here, will move it to proper thread)

[Moving Target]

with single threaded aps, yes. One prossesor looks after running of virus scanner etc, while other runs game. When Multithreaded games appear in the future then yes, there will be a big performance increase.

[Dwarden]

shinRaiden ... i got little question on You

let say You have 8 GB RAM (let be rich what about 16, 32, 64 http://forums.bistudio.com/oldsmileys/smile_o.gif) ... now ... where went Your "NOTHING TO DO WITH 64-BITS"

? http://forums.bistudio.com/oldsmileys/smile_o.gif http://forums.bistudio.com/oldsmileys/whistle.gif

[Ozzzzzzy]

Quote[/b] ]20 extra fps? I fail to see a real point in that,why does anyone even need 150 fps,after 20-30 its pretty much the sam.
My theory on why you need more frames per second is that they say the human eye can only see around 30 fps. If something can produce 60,100,200 or more than there must be gaps in between each frame. So by producing more fps you have more of a chance youre eyes frame will see the one being rendered.



Quote[/b] ]My uncle has a amd 64 processor and he tells me that he gets much better net speed in unreal tournament 2004.
he said he got like 14 or more in ping and now he get from 6-12 or something like that. he says its a big difference wehn playing games ***
Ya when I have the lowest ping I usely get allot more kills, If he upgraded to ***64 bit he probably got a new motherboard and it probably came with on board giga-lan, I read somewhere that it bypasses the pci bus (network card) and should be much faster. I think i did notice a diffrence with 64-bit internet explorer thoe.

I also read a little bit about the new windows vista and it said that it shuts down windows all together and just runs the game by itself like a console. and they are going to release a 64-bit version of it. Sounds good to me.

I cant comment on all that technical stuff but i would think if 64-bit wasn't better than 32-bit we would still be on 16-bit

[shinRaiden]

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]

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]

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

[EiZei]

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]

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]

Yea, it would be stupid to stop supporting the 64 community.... Thats a way of stopping the future gamers of buying a game, lol http://forums.bistudio.com/oldsmileys/smile_o.gif

[Scrub]

Woah, the word from 'The Man'. ***That pretty much sums up this thread.. http://forums.bistudio.com/oldsmileys/rofl.gif ***(Sums.. get it? ***http://forums.bistudio.com/oldsmileys/tounge2.gif ***http://forums.bistudio.com/oldsmileys/confused_o.gif ***http://forums.bistudio.com/oldsmileys/crazy_o.gif .. yeah, ok, it was terrible)

[darkpeace]

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]

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

[shinRaiden]

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]

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]

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]

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]

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]

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]

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&#33http://forums.bistudio.com/oldsmileys/wink_o.gif

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 http://forums.bistudio.com/oldsmileys/smile_o.gif

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 http://forums.bistudio.com/oldsmileys/yay.gif

[shinRaiden]

Woohoo! Geek fight! http://forums.bistudio.com/oldsmileys/biggrin_o.gif 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 http://forums.bistudio.com/oldsmileys/tounge2.gif

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 http://forums.bistudio.com/oldsmileys/smile_o.gif

[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? http://forums.bistudio.com/oldsmileys/rofl.gif http://forums.bistudio.com/oldsmileys/huh.gif

[Espectro]

so whats this mean in simple terms? ***http://forums.bistudio.com/oldsmileys/rofl.gif ***http://forums.bistudio.com/oldsmileys/huh.gif
dont buy it http://forums.bistudio.com/oldsmileys/smile_o.gif

[Zombie_Mod]

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 http://forums.bistudio.com/oldsmileys/tounge2.gif

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]

For the MMX 64 bit data bus you state exists, can you point me to some documentation?
Here (http://webster.cs.ucr.edu/AoA/Windows/HTML/SystemOrganization.html#998874), 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]

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]

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? ***http://forums.bistudio.com/oldsmileys/wow_o.gif

Edit: And if that's right, god forbid me ever installing a 64-bit OS!! http://forums.bistudio.com/oldsmileys/rofl.gif

[shinRaiden]

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.