64-bit executable

[5133p39 14]

How would he know? The game is closed source. We are entirely dependent on the developers to do this for us. Show us the code and maybe we could figure it out in time.

Well, logically, because of what he wrote, i presume he must have got a LOT of experience with C++ programming, especially 3d game engines, AI, networking, etc., because how could he know otherwise?

Especially since he's got no access to the ArmA3 source code - he must be a real genius to know everything about it even though he never seen it, right?

[bobby budnick 0]

Well, logically, because of what he wrote, i presume he must have got a LOT of experience with C++ programming, especially 3d game engines, AI, networking, etc., because how could he know otherwise?

Especially since he's got no access to the ArmA3 source code - he must be a real genius to know everything about it even though he never seen it, right?

No one is at fault here. People are just bitter about game developers being stuck in the past is all. Some us of have been running 64 bit systems for a decade.

[Insanatrix 0]

Myke;2340389']Excellent arguing i see.

Here again' date=' what does a 64bit exe and why it wouldn't work.

With 64bit, a application can use much more RAM than a 32bit exe can. Undisputed.

Now, why wouldn't it have any effect on the RV engine? Simple enough, the engine is designed to request required data direct from disc (we call this "data streaming") and not load into memory if not immediately needed. So, ArmA aswell as ArmA 3 are LAA enabled, so they can use more than just the regular 32bit memory address already. Now the one million dollar question: how much of this memory it could actually use it does use? One gigabyte? A bit more? And now as 64bit app, it could use even more memory but why should it? The engine is designed to stream required data direct from disc and discard data that is no longer needed.

It is actually like someone taking a 1dl drink from a 2dl glass. He doesn't want to drink more than this 1 dl so why do you try to give him a 2l glass? He still just fills it with 1dl as this is all he needs.

Even worse, the additional memory management workload with 64bit may even decrease the game performance. Like the guy above, it would be esier to handle the small 2dl glass than the big 2l glass.

So again, making a 64bit app wont magicaly increase the engines performance. It would require a major engine rework to actually benefit from it. A major reworks requires time and money, both aren't a unlimited source and it has to be considered if it is worth it. Obviously there are more important issues to address beforehand as the streaming engine is quite solid (not saying perfect, don't put that in my mouth).[/quote']

The fact that the game is streaming data from the disc rather than utilizing free memory is part of the reason that it is so capped in terms of utilizing the hardware. Sure, maybe the current implementation of the engine wouldn't benefit much from 64bit, I agree with you on that for the most part. However with the increase in sheer amount of data being streamed with each iteration of the RV engine and the slow nature of regular HDD's and SATA interfaces compared to memory bus bandwidth and speed, maybe it's time to look at rewriting it. Are we going to be data streaming from the HDD well into the future because the generally accepted excuse is that it's too time consuming and too hard to implement? I've already seen how much of a memory footprint ArmA 3 has and it's well over 7gb. To be able to address a great majority of that to free physical ram instead of needing to constantly stream off the HDD would be a large performance increase, but yes it would require a rewrite of how this game handle's it's memory mapping and utilization.

I would like to think that BI cares enough about the consumers of their products that they would take the time to do something right, rather than utilize old and outdated architecture simply because the better alternative is "too hard and too time consuming". If not, we're going to be looking at ArmA 6 running at 10fps on even the fastest computers possible, simply because the software is written for such an archaic and outdated method of memory mapping and streaming.

To clarify, what Myke is saying is that if they were to code the RV engine in 64bit the way it is now, there would still be a large portion of data that streams from the HDD and the game would still probably only use 1.5-2gb total memory because it's written for that limitation and it's written to utilize virtual memory as a stopgag to the 32bit memory limitation. In order for 64bit to make a difference, they would have to rewrite the engine and their streaming code to be able to dynamically utilize system memory and fill in the gap with virtual memory were needed, in order for there to be any substantial performance increase. If I'm reading Myke's responses correctly, apparently that is too hard to do.

To clarify you're analogy, it's like someone taking a 1L drink from a 2L glass, but in reality needing about 4L. He's programmed to only take a 1L drink, due to the limitation of the 2L glass. if you gave him a 4L glass and programmed him to take 4L from it, he would function much more optimally.

Edited March 16, 2013 by Insanatrix

[[frl]myke 14]

If I'm reading Myke's responses correctly, apparently that is too hard to do.

You read it incorrectly. It's not too hard, it is a matter of time and money (given that developers don't work for free). Both resources that are limited so it has to decided if the effort is worth the (to be expecting) result. Probably they had to decide if they further develop and improve a already working system of which every player can benefit, regardless of the used OS or completely rework the game engine and alienate users that don't have switched to a 64bit OS.

[calin_banc 19]

As far as I know, if own a Windows key, then you can download the kit and reinstall the 64 version of it (if you don't have the kit already). So, the only downside is a small one - "reinstall the OS". You don't exclude anyone like it's already being done with no DX 9/Win xp support and I don't think that's such a huge task. It's to much to say "they're not doing it for the people"; no, they're not doing it because at least with ArmA 3, this method of streaming extensively from HDD can still work good enough. ArmA 4 or some form of DLC may give Bohemia some space for experiment, but until then, we shouldn't expect much.

It will nice to know if a SSD will give a better performance and if a 64bit .exe would do the same if the engine would be written accordingly.

Edited March 16, 2013 by calin_banc

[Zordon 1]

It will nice to know if a SSD will give a better performance and if a 64bit .exe would do the same if the engine would be written accordingly.

1.No only better loading times.

2.Probably but not enough to make BI change from x32.

[Insanatrix 0]

Myke;2340923']You read it incorrectly. It's not too hard' date=' it is a matter of time and money (given that developers don't work for free). Both resources that are limited so it has to decided if the effort is worth the (to be expecting) result. Probably they had to decide if they further develop and improve a already working system of which every player can benefit, regardless of the used OS or completely rework the game engine and alienate users that don't have switched to a 64bit OS.[/quote']

So how can you say that it's not worth the effort to get rid of a system that primarily focus's on virtual memory on the HDD as the primary means of memory mapping, when you have the prevalence of 64bit computers that are out there right now? You're worried about alienating users that haven't switched to 64bit when your software is barely coping with the 32bit limit which can easily be shown through logging the memory footprint of the program. So the majority should suffer because of the minority?

There hasn't been a mainstream or really even budget 32bit processor in about 5 years. The only people you are alienating are people who do not have a 64bit OS installed, which is an easy and cheap fix. It seems like BI just want to be stuck in the past for the sake of being stuck in the past. The information is there for anyone to see, all they have to do is log memory usage while playing and you can see your virtual memory blow up beyond 5gb which is completely insane. That is over 3 times the physical memory usage.

How can you call this a working system that people can benefit from when people on extremely capable and high powered system are getting such crap performance because there is such a huge bandwidth bottleneck? It sounds to me like it's only working from the perspective of BI, who choose to sell the game in this state while apparently trying to sweep the issue under the rug. Us, the users of the software, are getting shafted simply because they are worried about alienating Fred and Bill, the last 2 remaining people on the planet running a 32bit OS for gaming. Sounds to me, from your argument, that BI has become more worried about their bottom line than the software that they produce and market.

This is about accountability, not entitlement. It's been an issue since ArmA 2, and apparently is just going to keep persisting until there's a big enough outcry from the consumer to affect a change.

[PuFu 4600]

So how can you say that it's not worth the effort to get rid of a system that primarily focus's on virtual memory on the HDD as the primary means of memory mapping, when you have the prevalence of 64bit computers that are out there right now? You're worried about alienating users that haven't switched to 64bit when your software is barely coping with the 32bit limit which can easily be shown through logging the memory footprint of the program. So the majority should suffer because of the minority?

It is because, the way the RV engine is designed, including ArmA3, the benefits would most likely be little to none, unless parts of the how the engine handles streaming content (models, textures) is changed/rewritten. To cut it short, it has, at least from where i am standing, little to do with the spread of 64 bit systems across the target group. It has a lot to do with the fact that RV engines simple doesn't buffer all that content in the ram, but it streams most directly out of the HDD, which is the reason why SSDs and RAM disks are indeed recommended for this game.

Should it be the other way around? Most likely, but bear in mind that RV has been built upon previous versions, when ram wasn't available for everyone at dirt cheap prices, and 2-4gb was the upper level. Things have changed since then.

If anything, you can blame legacy code for this sort of behaviour. Can this be easily changed? Doubtfully.

There hasn't been a mainstream or really even budget 32bit processor in about 5 years. The only people you are alienating are people who do not have a 64bit OS installed, which is an easy and cheap fix. It seems like BI just want to be stuck in the past for the sake of being stuck in the past. The information is there for anyone to see, all they have to do is log memory usage while playing and you can see your virtual memory blow up beyond 5gb which is completely insane. That is over 3 times the physical memory usage.

As previously said, it has little to do with 32 vs 64 bit cpus.

[jiltedjock 10]

Myke;2340389']Excellent arguing i see.

Here again' date=' what does a 64bit exe and why it wouldn't work.

With 64bit, a application can use much more RAM than a 32bit exe can. Undisputed.

Now, why wouldn't it have any effect on the RV engine? Simple enough, the engine is designed to request required data direct from disc (we call this "data streaming") and not load into memory if not immediately needed. So, ArmA aswell as ArmA 3 are LAA enabled, so they can use more than just the regular 32bit memory address already. Now the one million dollar question: how much of this memory it could actually use it does use? One gigabyte? A bit more? And now as 64bit app, it could use even more memory but why should it? The engine is designed to stream required data direct from disc and discard data that is no longer needed.

It is actually like someone taking a 1dl drink from a 2dl glass. He doesn't want to drink more than this 1 dl so why do you try to give him a 2l glass? He still just fills it with 1dl as this is all he needs.

Even worse, the additional memory management workload with 64bit may even decrease the game performance. Like the guy above, it would be esier to handle the small 2dl glass than the big 2l glass.

So again, making a 64bit app wont magicaly increase the engines performance. It would require a major engine rework to actually benefit from it. A major reworks requires time and money, both aren't a unlimited source and it has to be considered if it is worth it. Obviously there are more important issues to address beforehand as the streaming engine is quite solid (not saying perfect, don't put that in my mouth).[/quote']

Don't agree with your logic re the amount of work involved, as you see it. The data needs to be read off disk and into RAM, we all agree on that. What needs to change if there is a 64 Bit exe is the managment of data that has already been read off disk. This management framework already exists, otherwise how would the engine, in your words, know what to "discard" from RAM? Therefore, conceptually, the main piece of work is not rewriting how the game accesses the data, but how it manages it once it is already in memory.

[ric 1]

It is because, the way the RV engine is designed, including ArmA3, the benefits would most likely be little to none, unless parts of the how the engine handles streaming content (models, textures) is changed/rewritten. To cut it short, it has, at least from where i am standing, little to do with the spread of 64 bit systems across the target group. It has a lot to do with the fact that RV engines simple doesn't buffer all that content in the ram, but it streams most directly out of the HDD, which is the reason why SSDs and RAM disks are indeed recommended for this game.

Should it be the other way around? Most likely, but bear in mind that RV has been built upon previous versions, when ram wasn't available for everyone at dirt cheap prices, and 2-4gb was the upper level. Things have changed since then.

If anything, you can blame legacy code for this sort of behaviour. Can this be easily changed? Doubtfully.

As previously said, it has little to do with 32 vs 64 bit cpus.

how long have dual core proc's been out?...10 years...and quad's? 7+ years how can you justify the dev's not paying attention to or adapting to what would be main stream equipment 5+ years down the road...we are not talking about cutting edge equipment that was JUST released. we are talking about stuff that has been around for almost a decade.

what really puts things into perspective is that the new consoles wil 4/8 cores...even our phones are sporting dual/quad core proc's. Releasing a game in 2013 that is hobbled by its lack of ability to take FULL advantage of current hardware is not going to benefit anyone. no one is asking for some last minute rewrite but it is something that should have started 5+ years ago when the technological evolution of computer equipment was plane to see.

[Insanatrix 0]

It is because, the way the RV engine is designed, including ArmA3, the benefits would most likely be little to none, unless parts of the how the engine handles streaming content (models, textures) is changed/rewritten. To cut it short, it has, at least from where i am standing, little to do with the spread of 64 bit systems across the target group. It has a lot to do with the fact that RV engines simple doesn't buffer all that content in the ram, but it streams most directly out of the HDD, which is the reason why SSDs and RAM disks are indeed recommended for this game.

Should it be the other way around? Most likely, but bear in mind that RV has been built upon previous versions, when ram wasn't available for everyone at dirt cheap prices, and 2-4gb was the upper level. Things have changed since then.

If anything, you can blame legacy code for this sort of behaviour. Can this be easily changed? Doubtfully.

As previously said, it has little to do with 32 vs 64 bit cpus.

First of all, to say that ArmA 3 would not benefit from 64bit architecture is a fallacy. Being able to address more physical ram and less virtual ram would be a huge boon to the RV engine. I mean they had to design a system to get around the 32bit memory mapping limitation in the first place. Sounds kind of idiotic to then backpedal and say that it would benefit nothing from 64bit architecture, an architecture that lets you address large quantities of physical memory, when your program suffers from exhausting physical memory in the first place in a 32bit architecture.

Arguing anymore about it at this point is idiotic. It's pretty clear that BI just doesn't want to fix the issue. They would rather take the easy way out and keep trying to put band-aids on it. Using the slower SATA bandwidth is obviously much faster than addressing the issue and using physical memory across a bandwidth interface that's probably 50-100x faster :rolleyes:

[skadog 0]

So as it is now the game is CPU hungry and let face it not everyone has or exceeds an i5 CPU. So right there you are already reducing the possible customers as they wont have those required/recommended processors. :p I bet more of these system owners would be willing to spend their time and money to upgrade their OS and RAM rather than motherboard, CPU, PSU, RAM, and etc just to play A3.

I know.. It's already been said, it's a business decision.. that means they wont take the time and money to change it. They want to do this as cheaply and quickly as possible and still release a game that is going to sell to the most people they can sell it too. Unfortunately the people in charge are the people looking at the numbers. They don't care if the smallest number of people with the minimum requirements can't run the game well. Only that they can potentially run it.

[gammadust 12]

It's definitely a compromise, one i generaly also dislike. But only BI is in a position to find the oportunity worthy the effort, or any opportunity for that matter. Specially if the case is due to legacy code, which would imply a possibly unavailable workload allocation.

[ireun 1]

+1 Many people today have 64bit OS so that would make bid diffrance in game performance!

[white 1]

+1 Should be 64bits

+1 should have more async threads to make use of more than 2 cores

+1 should have more stuff running as shaders on opencl/cuda 100% in gpus like the ocean/clouds i mentioned on another topic.

i bet anyone would be able to get 50-100fps then.

[PuFu 4600]

First of all, to say that ArmA 3 would not benefit from 64bit architecture is a fallacy. Being able to address more physical ram and less virtual ram would be a huge boon to the RV engine. I mean they had to design a system to get around the 32bit memory mapping limitation in the first place. Sounds kind of idiotic to then backpedal and say that it would benefit nothing from 64bit architecture, an architecture that lets you address large quantities of physical memory, when your program suffers from exhausting physical memory in the first place in a 32bit architecture.

First of, i was trying to explain you, in a very decent manner, what you seem not to be willing to grasp: having a binary 64 bit without additional work on how the engine is streaming content doesn't make such a big difference. It is NOT fallancy. I have been using software on 64 bit since win XP went that way. I still do. There are certain parts of the said software (autodesk package mainly, but not exclusively), that still don't use more than 1 thread, or more than a few mb of memory, because not everything can be multithreaded, and not everything requires more ram.

Moreso, making the game LAA is not even close to making it 64 bit.

What i am saying is that you, and a lot of other, are under the impression that if BI would put time and resources to getting a 64 binary, the game will surely run miles better. It just isn't the case i am afraid. While 64 is indeed the future, there is a lot more that would need to be done prior to making a 64 binary (like how the game handles the data). Otherwise, it is futile. And btw, 64 has nothing to do with a application being able to properly multithreaded.

Arguing anymore about it at this point is idiotic. It's pretty clear that BI just doesn't want to fix the issue. They would rather take the easy way out and keep trying to put band-aids on it. Using the slower SATA bandwidth is obviously much faster than addressing the issue and using physical memory across a bandwidth interface that's probably 50-100x faster :rolleyes:

I am sorry to say, but you are making a foul out of yourself: changing to 64 bit doesn't mean the game won't continue to stream off the HDD, instead of caching that data to memory. It just doesn't work that way.

---------- Post added at 20:18 ---------- Previous post was at 20:16 ----------

+1 Should be 64bits

+1 should have more async threads to make use of more than 2 cores

+1 should have more stuff running as shaders on opencl/cuda 100% in gpus like the ocean/clouds i mentioned on another topic.

i bet anyone would be able to get 50-100fps then.

Arma obviously sees and uses all my 6 cores. It doesn't use my other virtual 6 cores (threads) though (on a 6c/12t i7 970@4Ghz and 24gb ram)

[[frl]myke 14]

@PuFu

don't waste too much energy on this topic or i will have to rename your account to "Don Quixote". ;)

[Insanatrix 0]

First of, i was trying to explain you, in a very decent manner, what you seem not to be willing to grasp: having a binary 64 bit without additional work on how the engine is streaming content doesn't make such a big difference. It is NOT fallancy. I have been using software on 64 bit since win XP went that way. I still do. There are certain parts of the said software (autodesk package mainly, but not exclusively), that still don't use more than 1 thread, or more than a few mb of memory, because not everything can be multithreaded, and not everything requires more ram.

Moreso, making the game LAA is not even close to making it 64 bit.

What i am saying is that you, and a lot of other, are under the impression that if BI would put time and resources to getting a 64 binary, the game will surely run miles better. It just isn't the case i am afraid. While 64 is indeed the future, there is a lot more that would need to be done prior to making a 64 binary (like how the game handles the data). Otherwise, it is futile. And btw, 64 has nothing to do with a application being able to properly multithreaded.

I am sorry to say, but you are making a foul out of yourself: changing to 64 bit doesn't mean the game won't continue to stream off the HDD, instead of caching that data to memory. It just doesn't work that way.

---------- Post added at 20:18 ---------- Previous post was at 20:16 ----------

Arma obviously sees and uses all my 6 cores. It doesn't use my other virtual 6 cores (threads) though (on a 6c/12t i7 970@4Ghz and 24gb ram)

Who said they wouldn't have to rewrite how the engine handles memory addressing? I've said many times that they would have to rewrite it. 64bit architecture ALLOWS you to address beyond 4gb of physical memory, They would still have to rewrite the engine to be able to utilize that much memory and get rid of the HDD streaming. It seems that you want to put your own conclusions into my words.

Where did I say making the game LAA is anywhere remotely like making it 64bit? Where did I say 64bit has anything to do with multi-threading? Are you even reading my posts? I've said numerous time that the engine needs a rewrite, it needs to utilize 64bit architecture because the memory footprint of the RV engine has grown so far beyond the 32bit limitation that you are now relying more on your hard drive to act as a memory buffer 3 times over the actual utilized physical memory, than you are relying on your physical memory to feed data and texture's to the GPU and CPU.

Secondly, I know you were trying to argue your point in a decent manner, show me where I argued my point in an indecent manner. Otherwise I see no relevance to your statement other than to try and draw sympathy like you're the poor lone fanboy defending BI from the evil 64bit aggressor's.

It is actually you that has the wrong idea, thinking that we are simply saying a 64bit binary will solve everything. What we are saying is that the game engine needs to be rewritten to utilize the larger memory addressing of 64bit architecture, because the current method of streaming over 5gb of data to and from physical memory, just plain sucks and is hindering performance and productivity of the software for a large general population of user's. This should have been a top priority since ArmA 2 as the RV engine suffered from the same issue's then, and common sense and logic would tell you that it's only going to get worse with each revision as texture sizes grow and as the game and it's engine expand, therefor needing increased memory capacity to function. Excuse most of us that could see this coming from a mile away, being frustrated and wanting to voice our opinions about the issue. It doesn't help when you have both moderator's and user's misrepresenting the issue as if to say that we aren't asking BI to actually recode the game for a 64bit architecture.

[gossamersolid 155]

+1 Should be 64bits

64bits

bits

It's not 64 bits, it's 64-bit

Ontopic: Why is this topic still open? BIS has said it's not going 64-bit, there's no discussion here.

[Insanatrix 0]

It's not 64 bits, it's 64-bit

Ontopic: Why is this topic still open? BIS has said it's not going 64-bit, there's no discussion here.

Because not everyone are sheep. Would you rather people stop supporting BI because of bad moves or voice their opinions and argue their cases against even the most asinine of counter-arguments? Honestly I thought that's what the point of this alpha was, and what the point of feedback was. To give the developers an idea of what they are doing right and what they are doing wrong. Like I said, Maybe when we're topping out at 5fps and the game runs like a slideshow, we'll see something done.

Edited March 16, 2013 by Insanatrix

[gossamersolid 155]

Because not everyone are sheep. Would you rather people stop supporting BI because of bad moves or voice their opinions and argue their cases against even the most asinine of counter-arguments?

I'd rather stop seeing posts about 64-bit executables when they have said they aren't doing it. There's literally nothing to argue. It's plain and simple not going to happen.

[Insanatrix 0]

I'd rather stop seeing posts about 64-bit executables when they have said they aren't doing it. There's literally nothing to argue. It's plain and simple not going to happen.

You ever said you weren't going to do something, then factual data caused you to change your mind?

[white 1]

Arma obviously sees and uses all my 6 cores. It doesn't use my other virtual 6 cores (threads) though (on a 6c/12t i7 970@4Ghz and 24gb ram)

it sees but doesnt use them properly, have you ever looked at armas threads on an api monitor? theres mainly 1 thread handling the game, sync and ai on the first core, and crap like clouds and physx spread on other cores that have to wait on the first core to begin with. i have a 6 core aswell, and ive posted screenshots of performance test with only 2 of them avaiable to the game, guess what, same fps, higher cpu usage 90%+ on both cores. the game main game/ai doesnt have enough threads to use more cores, thus, a 6 or 8 cores perform the same as a dual core because the first core is always bottlenecked with anything going on. (worse if the dual core is on a better platform and have higher frequency)

http://forums.anandtech.com/showthread.php?t=2306247

Edited March 16, 2013 by white

[dayglow 2]

Probably because you can't asynchronously process the data. The threads have to synced for the game to work. Each thread relies on data from other threads. Thus you have the master thread as you see syncing all the data from the other threads.

Eagle Dynamics is facing the same issues with their DCS line of sims. Breaking off different threads doesn't magically speed everything up because each thread is reliant the others to function.

[jiltedjock 10]

but it streams most directly out of the HDD,

You seem to think that this precludes any benefits from a larger address space. Where do you think it is being streamed to? Into RAM of course. When you run Arma 2 on Win7 64Bit, which benefits from more RAM being addressable by the application than on a 32 Bit OS, there is noticeably less hdd activity, because the data is still in RAM after the initial stream. Which suggests to me that the effort of work required for the engine to benefit from a 64Bit address space is less than you imagine.