Arma 3 Engine - What would have been a better option and what can we learn?

[calin_banc 19]

To appease people yelling about concurrency, just spawn few native threads in the background and make them increase a counter in an endless loop.

BAM! 100% CPU utilization.

Well, just use more physics then on the free cpu power - too bad physx was chosen. BF has, in general, more stuff going on at once in a smaller map, so although the action is not that spread in scale, is more demanding, concentrated.

That aside, they've made some optimization through DX11.1 that really boosts CPU performance, don't know if would help ArmA, but it sure looks interesting - along side tiled resources, tessellation, GI, etc.

[xendance 3]

Well, just use more physics then on the free cpu power - too bad physx was chosen. BF has, in general, more stuff going on at once in a smaller map, so although the action is not that spread in scale, is more demanding, concentrated.

That aside, they've made some optimization through DX11.1 that really boosts CPU performance, don't know if would help ArmA, but it sure looks interesting - along side tiled resources, tessellation, GI, etc.

PhysX is multi-threaded. How else would it be able to take advantage of CUDA acceleration? ;)

[calin_banc 19]

It doesn't run on the CPU as well as other multi-thread software. Strange they didn't use Havok which has other tools as well.

[Leon86 13]

PhysX multithreads just fine on the cpu. Lots of games dont take advantage of it because it's already running great compared to the console versions.

[calin_banc 19]

Here we are not talking about any console version. If PhysX is running on 2 or even 3 threads in ArmA 3, it's great - http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/ . Little details like the smoke from a grenade or explosion that is blown away by wind or a helicopter is nice - but totally immersion breaking when it goes through solid objects. Anyway, cool stuff experimenting with everything the game has to offer. :)

[Reuben5150 2]

Here’s just a small list of what I’ve seen people asking for lately...

Who exactly ? where do these great minds reside ?

Cant tell is this is even serious.

[Hameedo 10]

I have a few points to add to the discussion ..

This is a video discussing ARMA 3 graphics and performance , what do you guys think about the points mentioned :

[windies 11]

No. "Better" concurrency is a way to achieve better performance. And, to me, the definition of "better concurrency" is "some level of concurrency that improves performance" - not necessarily "increased concurrency".

Measuring concurrency is only a valid measure of performance if nothing else changes. If something else changes in the way the engine works (as it sounds like it would have to in this case to increase concurrency) then we don't know what the actual effect on performance would be. And performance improvement is the whole point of the exercise. I, personally, would be happy to see a reduction in concurrency if that somehow improved performance. Because I don't care what my CPU's doing, or if my expensive GPU is somehow offloading calculations to the RAID controller, or if my RAM is being bypassed entirely and everything's being done on HDD cache - if all that nonsense somehow makes the game run better then I've scored a win.

This whole issue reminds me of what I see in business or engineering, where people focus attention and effort on things that are easy to measure, rather than the things they should actually care about. They choose a parameter which is one of several important parameters and optimize that without an understanding of the effect of their actions on the whole system and therefore the final result they're after. For example, focusing exclusively on improving cashflow without proper consideration of the effect on long-term profit & loss. Or on maximising combustion chamber temperature (which is a driving factor in thermodynamic efficiency) without considering the related increase in wear, servicing costs, cooling requirements, and therefore the true impact on total cost to run - which is the real measure of success.

BI should be maximising the ratio of game performance increase compared to their effort. If increasing concurrency is the most efficient (in the performance gain per effort measure), then that's what they should focus on. If improving the algorithm efficiency in a single thread can achieve the same performance gain for less effort on their part, then they should do that. And if changing 15 different things in 15 different ways (some possibly related to concurrency) is the best, then that's what they should do.

Yeah man, that must be why ArmA 3 is the bastion of typical PC gaming performance.....

And you literally said the exact same thing that I did. Concurrency is a way to achieve better performance. better concurrency generally leads to increased concurrency. That doesn't translate into all CPU core's screaming at 100%, but rather equal load across all core's at or around 80-90% load. The lopsided load you can see when running ArmA 3 just screams, "I'm single threaded trying to pretend I'm multi-threaded!".

[10t 12]

And you literally said the exact same thing that I did.

I hope not; I wasn't trying to. I was trying to say the exact same thing Maruk said and has said before. And what Ondřej wrote back in 2009 which Maruk keeps referring to. Particularly the paragraph "Goal and Means". What I wrote could maybe be restated as "The performance problem is multidimensional, and focusing exclusively on only one of those dimensions may not be the best way to increase performance."

Let me put it this way:

If BIS can improve performance overall by 10% in 2 years (assuming it can be objectively measured and expressed that way) by working on increasing concurrency, or they can improve performance by 20% overall in 1 year by doing "something else"0, then I hope they ignore concurrency and focus on the "something else".

I've re-read your post and mine a couple of times, but I'm still struggling to see how you're interpreting my post. Particularly the "Yeah man, that must be why ArmA 3 is the bastion of typical PC gaming performance....." bit - I don't know where I said anything that could be read as any sort of comment on Arma's current performance, let alone "Arma performs well". Perhaps you could read through it again with the above in mind? At any rate, all this has been discussed already in the threads I linked to above.

[squirrel0311 16]

Who exactly ? where do these great minds reside ?

Cant tell is this is even serious.

....Have you been reading the forums?

[windies 11]

`

I hope not; I wasn't trying to. I was trying to say the exact same thing Maruk said and has said before. And what Ondřej wrote back in 2009 which Maruk keeps referring to. Particularly the paragraph "Goal and Means". What I wrote could maybe be restated as "The performance problem is multidimensional, and focusing exclusively on only one of those dimensions may not be the best way to increase performance."

Let me put it this way:

If BIS can improve performance overall by 10% in 2 years (assuming it can be objectively measured and expressed that way) by working on increasing concurrency, or they can improve performance by 20% overall in 1 year by doing "something else"0, then I hope they ignore concurrency and focus on the "something else".

I've re-read your post and mine a couple of times, but I'm still struggling to see how you're interpreting my post. Particularly the "Yeah man, that must be why ArmA 3 is the bastion of typical PC gaming performance....." bit - I don't know where I said anything that could be read as any sort of comment on Arma's current performance, let alone "Arma performs well". Perhaps you could read through it again with the above in mind? At any rate, all this has been discussed already in the threads I linked to above.

You did say the same thing that I did, sorry if you weren't trying to.

In reality, working on better concurrency shouldn't be some separate taboo thing, it should be part of a normal developer workflow anymore. It should be a goal just like any other. I've said exactly why you can see that the RV engine is terrible at using multiple core's and it has nothing to do with core usage being at 100% every nanosecond of processing time. It's about the workload across core's and how it fluctuates based on load and what type of load causes those fluctuations. I said that above, but you, Maruk and Dwarden always conveniently ignore what I'm saying to get on your soap boxes and preach a bunch of BS that's either untrue or just more smoke and mirrors.

I've shown in separate threads how the RV engine with ArmA 3 assets uses over 4gb of the 32gb addressing limitation by using the "hackish" file mapping API workaround they devised a long time ago so they wouldn't have to code their engine for 64 bit addressing and memory mapping. They say that 64 bit addressing wouldn't help, yet they easily surpass the 32 bit limitation through the file mapping API. They say that the engine is multicore ready and multithreaded, yet you can see just by the typical usage and how it responds to load, that it's completely held back by the primary thread under light to moderate load. Even their blog about when they added the whole file mapping scheme says that 64 bit is the future, yet when it comes time to implement it, they don't? All we have anymore are quad, hexa and octo core processor's, but according to a developer from BI and the owner of the company, concurrency and parallel processing and associated usage and load across all those core's in conjunction with engine load and engine performance, are the wrong metrics to be focusing on.

I'm sorry, but it sounds like developers trying to cover their asses for taking the easy way out and doing just like you said, focusing on little things here and there to get them better performance quick, rather than focusing on the future picture for both their franchise and their engine and working towards that future goal. If you want to support that and defend that, by all means keep doing it. You wouldn't be the first and you certainly won't be the last.

My remark was sarcasm about how obviously they are doing things right, it's working out so great for them isn't it? That's why it must be the epitome of your typical PC gaming performance, seeing as how they are a company who prides themselves on developing exclusively for the PC because of it's "power", power that their engine can't use correctly, but ironically saves them from having to develop and program properly for a platform to squeeze out all the performance out of it because they're working with set hardware rather than a range of hardware that they can then blame if things don't work properly.

[10t 12]

... the wrong metrics to be focusing on.

This might be a semantics thing. Concurrency is the wrong metric (standard of measurement) for Performance. It's also not the goal.

Goal: Performance increase.

Relevant metrics: FPS, graphical quality, number of objects displayed simultaneously, responsiveness, entities simulated (bullets, vehicles, weather, etc).

Tools available to achieve Goal: Concurrency; code efficiency; other clever things I don't know because I'm no programmer.

How about this hypothetical example: What if BIS rewrote the code in a way that was totally multi-core aware and could exploit 100% of the power of every core when needed? That sounds great, but if it didn't improve my experience (as measured with the above metrics) then it's no help. And it's possible it wouldn't improve them. It's even possible that a rewrite to that model would reduce performance (the spawn idle-loop threads mentioned above is an extreme example). And sure, doing that work to make the engine worse would be ridiculous - but it demonstrates that measuring concurrency on your machine now is not a valid way of measuring the performance of the game. Then again, if the rewrite did improve those metrics, then it would have improved performance.

Or another example. I was nearly going to write "complexity of simulated entities" in the metrics above. But I was about to make the same mistake. I don't care how complex the algorithm defining the behaviour of flocks of birds in a game (for instance) is. All I care about is their veracity. Increasing the complexity is one way to do that (e.g. individual neural networks and self-programming expert systems for each bird), but if I can come up with a simple algorithm that mimics flocking indistinguishably (the "maintain ideal distance from neighbours" idea) then I've done a better job. Similar things could be said for armour penetration. Simulating every rivet and internal stresses around weld seams would be one way to increase the armour penetration veracity. But a cleverly weighted random dice roll with a few key input parameters might do an equally good - or superior - job, and therefore be better.

Really, I'm not saying anywhere that "increasing concurrency won't improve performance" or "BIS should not invest effort in increasing concurrency", just that it's not a valid proxy for performance and therefore not a goal in and of itself.

[windies 11]

This might be a semantics thing. Concurrency is the wrong metric (standard of measurement) for Performance. It's also not the goal.

Goal: Performance increase.

Relevant metrics: FPS, graphical quality, number of objects displayed simultaneously, responsiveness, entities simulated (bullets, vehicles, weather, etc).

Tools available to achieve Goal: Concurrency; code efficiency; other clever things I don't know because I'm no programmer.

How about this hypothetical example: What if BIS rewrote the code in a way that was totally multi-core aware and could exploit 100% of the power of every core when needed? That sounds great, but if it didn't improve my experience (as measured with the above metrics) then it's no help. And it's possible it wouldn't improve them. It's even possible that a rewrite to that model would reduce performance (the spawn idle-loop threads mentioned above is an extreme example). And sure, doing that work to make the engine worse would be ridiculous - but it demonstrates that measuring concurrency on your machine now is not a valid way of measuring the performance of the game. Then again, if the rewrite did improve those metrics, then it would have improved performance.

Or another example. I was nearly going to write "complexity of simulated entities" in the metrics above. But I was about to make the same mistake. I don't care how complex the algorithm defining the behaviour of flocks of birds in a game (for instance) is. All I care about is their veracity. Increasing the complexity is one way to do that (e.g. individual neural networks and self-programming expert systems for each bird), but if I can come up with a simple algorithm that mimics flocking indistinguishably (the "maintain ideal distance from neighbours" idea) then I've done a better job. Similar things could be said for armour penetration. Simulating every rivet and internal stresses around weld seams would be one way to increase the armour penetration veracity. But a cleverly weighted random dice roll with a few key input parameters might do an equally good - or superior - job, and therefore be better.

Really, I'm not saying anywhere that "increasing concurrency won't improve performance" or "BIS should not invest effort in increasing concurrency", just that it's not a valid proxy for performance and therefore not a goal in and of itself.

The problem with your whole argument, is that it goes against the tide of technology as it stands today and in the future. Saying that ArmA would perform better as a single threaded application versus a multi-threaded application is foolish. Even if you could get it to perform as good or better than a proper multi-threaded application somehow, you're settings yourself up for failure further down the road.

Do you honestly think that the RV engine can fully sustain itself on one core alone, now or even into the future? What's multi-threaded in this engine? AI pathfinding, File ops and what else?

Scripting is on one core, sound is on one core, physics are on one core though may be multi-threaded since they use PhysX, AI behavior's and associated scripting are on one core, general processing of things like bullets and environment is all done on one core, rendering is done on one core.

I also never said concurrency was a goal. I said performance is a goal and better concurrency is a way to achieve that goal. Do I need to quote my original post that started this argument? Here I will do it for you since you obviously don't understand the argument or anything about it.

What about better performance through better concurrency? Saying that process concurrency is not a goal, is kind of misleading because performance is the goal, better concurrency is the way to achieve that goal. After all, more operations per second is better in any sense of computing.

Let me Reiterate, I never said concurrency was a goal.

I said that saying process concurrency is not a goal and is unimportant is misleading because while it's not a goal, it's a way to achieve your goal. That's kind of funny, because it's the exact same thing that you said throughout your entire argument, yet you don't have the first clue as to what it even means.

Concurrency would be separate threads running in parallel across multiple scale-able cores. It's not 100% usage across all core's all of the time. It's aspects of the engine running separately and concurrently across multiple core's within one program. Through CPU usage you can see the load across core's. You can see that while one core bears most of the load, the other core's have very little load. Mostly due to the fact that the only thing multi-threaded within this engine is AI pathfinding and file operations, both of which are the least demanding of any other subsystem of the engine, which again you can extrapolate from the CPU usage graph.

I'm glad you don't care about how performance is achieved within the engine, but it begs the question, why are you arguing about how performance is achieved within the engine if you don't care and you don't understand it? Is it because someone being critical of the developers set off little warning bells in that special area inside your head?

[jiltedjock 10]

This might be a semantics thing. Concurrency is the wrong metric (standard of measurement) for Performance. It's also not the goal.

Goal: Performance increase.

Relevant metrics: FPS, graphical quality, number of objects displayed simultaneously, responsiveness, entities simulated (bullets, vehicles, weather, etc).

Tools available to achieve Goal: Concurrency; code efficiency; other clever things I don't know because I'm no programmer.

How about this hypothetical example: What if BIS rewrote the code in a way that was totally multi-core aware and could exploit 100% of the power of every core when needed? That sounds great, but if it didn't improve my experience (as measured with the above metrics) then it's no help. And it's possible it wouldn't improve them. It's even possible that a rewrite to that model would reduce performance (the spawn idle-loop threads mentioned above is an extreme example). And sure, doing that work to make the engine worse would be ridiculous - but it demonstrates that measuring concurrency on your machine now is not a valid way of measuring the performance of the game. Then again, if the rewrite did improve those metrics, then it would have improved performance.

Or another example. I was nearly going to write "complexity of simulated entities" in the metrics above. But I was about to make the same mistake. I don't care how complex the algorithm defining the behaviour of flocks of birds in a game (for instance) is. All I care about is their veracity. Increasing the complexity is one way to do that (e.g. individual neural networks and self-programming expert systems for each bird), but if I can come up with a simple algorithm that mimics flocking indistinguishably (the "maintain ideal distance from neighbours" idea) then I've done a better job. Similar things could be said for armour penetration. Simulating every rivet and internal stresses around weld seams would be one way to increase the armour penetration veracity. But a cleverly weighted random dice roll with a few key input parameters might do an equally good - or superior - job, and therefore be better.

Really, I'm not saying anywhere that "increasing concurrency won't improve performance" or "BIS should not invest effort in increasing concurrency", just that it's not a valid proxy for performance and therefore not a goal in and of itself.

If you offload the mission AI to a separate core by running your mission on a dedicated server instance - on your quad core alongside your client - your client performance, as measured by average FPS in the client, is better and less prone to spikes. Additionally, the mission AI is usually noticeably better. Finally, all the TPW suppression, GL4 or whatever else scripts you are running are local to the server which again takes the load off the client.

Without radical changes to the engine, which are unlikely to happen, I would have thought that making this approach a more standard option for quad and above cpus might be a way forward over the next couple of years.

Edited October 14, 2013 by jiltedjock

[10t 12]

I also never said concurrency was a goal. I said performance is a goal and better concurrency is a way to achieve that goal. Do I need to quote my original post that started this argument? Here I will do it for you since you obviously don't understand the argument or anything about it.

Actually, how about I quote it, as I did in my first reply in this thread:

What about better performance through better concurrency? Saying that process concurrency is not a goal, is kind of misleading because performance is the goal, better concurrency is the way to achieve that goal. After all, more operations per second is better in any sense of computing.

No. "Better" concurrency is a way to achieve better performance.

Even in your own quote of yourself, it's clear that you said "better concurrency is the way to achieve that goal" (emphasis added). And everything I have written since has been in response to that.

I'm glad you don't care about how performance is achieved within the engine, but it begs the question, why are you arguing about how performance is achieved within the engine if you don't care and you don't understand it? Is it because someone being critical of the developers set off little warning bells in that special area inside your head?

You're right, it should have begged that question. Because I don't think I argued anywhere in any of my posts in this thread about how performance is achieved within the engine. All I have said anywhere in any of them (collected here for your convenience: 1, 2, and 3) is that it's important to be careful to measure the right thing to achieve your goal in order to achieve it the most efficient way.

Again, I really think you aren't actually reading the words people have written. You might want to re-read the posts you're complaining about being full of "smoke and mirrors" with an open mind, because I think at least some of the smoke is a misconception or prejudgement on your part about what they actually say.

Edited October 14, 2013 by 10T

[windies 11]

Actually, how about I quote it, as I did in my first reply in this thread:

Even in your own quote of yourself, it's clear that you said "better concurrency is the way to achieve that goal" (emphasis added). And everything I have written since has been in response to that.

You're right, it should have begged that question. Because I don't think I argued anywhere in any of my posts in this thread about how performance is achieved within the engine. All I have said anywhere in any of them (collected here for your convenience: 1, 2, and 3) is that it's important to be careful to measure the right thing to achieve your goal in order to achieve it the most efficient way.

Again, I really think you aren't actually reading the words people have written. You might want to re-read the posts you're complaining about being full of "smoke and mirrors" with an open mind, because I think at least some of the smoke is a misconception or prejudgement on your part about what they actually say.

Wow, talk about arguing semantics.

I'll give it to you though, if I had said "better concurrency is A way to achieve that goal", it wouldn't come off as an absolute. I guess maybe I thought you would be smart enough to argue the point rather than the semantics of how I made my point. Foolish me....

Still though, I'm open to you telling me how I said that better concurrency was the ultimate goal rather than a way to achieve the ultimate goal. Seriously, semantics is kinda working for you at this point, keep it going ;).

[ric 1]

@10T and Windies

heres your solution guys...unfortunately A dev dismissed it as "middleware" :( ...but it sounds good though:)

http://www.texasmulticoretechnologies.com/services/

[mach2infinity 12]

Is it because someone being critical of the developers set off little warning bells in that special area inside your head?

Fascinating debate here by the way but I did laugh at the above. :D

[Smurf 12]

Getting hard to come back to A3 after playing GTA 5.

Hope Arma 4 comes into another engine.

[fumanwho 10]

Wow, talk about arguing semantics.

I'll give it to you though, if I had said "better concurrency is A way to achieve that goal", it wouldn't come off as an absolute. I guess maybe I thought you would be smart enough to argue the point rather than the semantics of how I made my point. Foolish me....

Still though, I'm open to you telling me how I said that better concurrency was the ultimate goal rather than a way to achieve the ultimate goal. Seriously, semantics is kinda working for you at this point, keep it going ;).

When you said "better concurrency is the way to achieve that goal. After all, more operations per second is better in any sense of computing".

---------- Post added at 00:06 ---------- Previous post was at 00:01 ----------

10lt has written 4 posts explaining something to you which you still do not understand. He is not having an argument with you. He was trying to help.

[windies 11]

When you said "better concurrency is the way to achieve that goal. After all, more operations per second is better in any sense of computing".

---------- Post added at 00:06 ---------- Previous post was at 00:01 ----------

10lt has written 4 posts explaining something to you which you still do not understand. He is not having an argument with you. He was trying to help.

Ok, and exactly why are more operations per second NOT better? Optimizing generally means clearing up useless operations for more important or pertinent operations. But being able to do more calculations or more operations per second is generally better in any sense of computing. It's up to the developer to make sure those operations are actually useful and not wasted.

Again how am I not understanding this? Pretty sure I understand it just fine.

[nodunit 397]

Getting hard to come back to A3 after playing GTA 5.

Hope Arma 4 comes into another engine.

You know that is not going to happen, and that is even IF there is an Arma 4.

[windies 11]

You know that is not going to happen, and that is even IF there is an Arma 4.

I think if they spent the time fixing the issue's wrong with this engine, they wouldn't need another engine. Of course it's not to say it everything would be easy to fix, it might come down to whether or not scrapping the RV engine in favor of something built from the ground up to suit their needs would be better. Either way though, Too many flaws in the engine have been ignored because of the "I am sorry to disappoint you, but some things are really too hard and we are not willing to spend the time on them." attitude and it's lead us to this point.

[fumanwho 10]

Ok, and exactly why are more operations per second NOT better? Optimizing generally means clearing up useless operations for more important or pertinent operations. But being able to do more calculations or more operations per second is generally better in any sense of computing. It's up to the developer to make sure those operations are actually useful and not wasted.

Again how am I not understanding this? Pretty sure I understand it just fine.

My post is about a question you asked. I said nothing about armas performance and i cant understand why you think that i did. Are you sure you fully understood my post?

[Smurf 12]

You know that is not going to happen, and that is even IF there is an Arma 4.

Honestly, it has to happen if an A4 ever happens. Or they manage to get a rabbit out of the hat with RV, which is very unlikely.

You can teach some tricks to an old dog, but the dog don't get younger with that, will be somewhat rusted\slower in doing so and eventually it will die.

And the RV "selling points" are becoming standards with new engines (these are capable of incredible things, like rivers :j:)