Low CPU utilization & Low FPS

[Dwarden 1124]

to some degree it's possible, at least some of that is stuck on problem of thread safety (for laics it means crashing and instability/freezes etc)

it's obvious we can't introduce (especially now) such changes w/o it being stable

[windies 11]

to some degree it's possible, at least some of that is stuck on problem of thread safety (for laics it means crashing and instability/freezes etc)

it's obvious we can't introduce (especially now) such changes w/o it being stable

Yeah I can understand that. I just have noticed that the biggest cause of low CPU/GPU utilization stems from the number of AI active. It seems to be mostly from their behavior scripts and FSM's, for instance if you set them to careless and therefor bypass a majority of their formation FSM's, GPU usage will go way up and so will your FPS. Hopefully you guys can find a good stable way to parallel process the AI behavior's.

[mt 10]

Two and a half interesting posts in a row. Keep it up, Dwarden!

So we can "hope" that in maybe some months (but for sure not around release) some larger changes could improve FPS.

Up to then, we gotta look for the intel CPU with the highest per-core performance and overclock that to the max.

What I still don't understand:

How is it possible that path-planning of AI or running some miscellaneous client (or even server side?) scripts is so tightly coupled with rendering the scene?

Why do you have to wait for some script (step) to draw another frame?

[oldbear 390]

I can play Arma3 on a low end rig such as my n°3 "Athlon II x2 250/ GS 450" with high CPU utilization : 80% to 100% on each 2 cores and with 25/30 FPS. Will it be still possible in the future ?

[Vixente 10]

to some degree it's possible, at least some of that is stuck on problem of thread safety (for laics it means crashing and instability/freezes etc)

it's obvious we can't introduce (especially now) such changes w/o it being stable

I suppose this game is made using C++ and you guys probably know what i'm about to tell you, but anyway:

C++11 has some cool new features for concurrency and thread safety. You might wanna check those.

- atomic type variables are race-proof. You can write to an atomic variable in one thread and read it from another thread and they'll behave fine automatically.

- async keyword will (probably) run the specified function in another thread. You can pass some parameters too.

- future and promise are also used to run tasks and get the result, ideally from another thread.

- Of course you have thread which is now easy than ever to make new threads.

There are a few more, but these are already pretty important and game-changing.

[jumpinghubert 48]

How is it possible that path-planning of AI or running some miscellaneous client (or even server side?) scripts is so tightly coupled with rendering the scene?

Why do you have to wait for some script (step) to draw another frame?

nice posting. I think thats exactly causes the usage behavier of cpu/gpu depending on amount of ai: more ai doesn´t result in more cpu-usage, it cuts only cpu ressources the gpu needs (less gpu-usage with more ai).

[Furret 0]

End-users are limited to black-box testing. We can't really reach concrete answers and are limited to making informed estimates/guesses as to what are the causes of low CPU utilisation. The only people who really know what causes these issues are those with access to the source, i.e. the developers. Everything else is just conjecture.

Edited August 31, 2013 by Furret

[ric 1]

What I still don't understand:

How is it possible that path-planning of AI or running some miscellaneous client (or even server side?) scripts is so tightly coupled with rendering the scene?

Why do you have to wait for some script (step) to draw another frame?

i believe this is because core 0 is the primary worker and when it becomes overloaded everything slows down ...information to render become less per second(FPS drop)

I did some experimenting with my server , i disabled 3 of the 4 cores and started my server...it loaded as normal but crashed when the AI spawned, it seems the AI are bound to core 1 and will scale across other available cores but the primary engine is bound to core 0 and as such becomes the bottle neck.

---------- Post added at 14:26 ---------- Previous post was at 14:19 ----------

to some degree it's possible, at least some of that is stuck on problem of thread safety (for laics it means crashing and instability/freezes etc)

it's obvious we can't introduce (especially now) such changes w/o it being stable

Turnkey multicore programming services using SequenceLâ„¢

No risk pre-project assessment of multicore acceleration potential

Produces transportable threaded C++ code

Whether you need to convert an existing application or are starting a new development,

Upgrade your application for multicore performance! ThreadedSâ„¢ is the fastest path to optimized, parallel applications.

come on Dwarden...its your chance to shine...you can become the hero of the Arma community :) take a chance and contact them :)

[Dwarden 1124]

again, throwing 'multithreading' middlewares on engine isn't solution to the problem,

sometimes such 'change' means months to years rewriting to just discover such middleware is subpar ...

there is well known Intel TBB for example http://www.threadingbuildingblocks.org/faq and many others ...

(we already use TBB memory allocator anyway)

[Furret 0]

i believe this is because core 0 is the primary worker and when it becomes overloaded everything slows down ...information to render become less per second(FPS drop)

My understanding of multithreading is you have a primary process that can spawn sub-threads. So, core 0 has the primary process and each successive core can run many sub-threads. What's odd is there seems to be some sort of lock being used that causes the rendering part of the thread to wait until such things as AI are processed(MutEx lock perhaps?, Rendering has lower priority than AI thread?). I lack sufficient experience with multithreaded programming to explain why this is so.

[ric 1]

again, throwing 'multithreading' middlewares on engine isn't solution to the problem,

sometimes such 'change' means months to years rewriting to just discover such middleware is subpar ...

there is well known Intel TBB for example http://www.threadingbuildingblocks.org/faq and many others ...

(we already use TBB memory allocator anyway)

thnx for the link TBB looks like something to used during development as were TMT is post development.

years of rewriting? no offense and i mean that , did you read what TMT does?

The compiler automatically identifies opportunities for parallel processing in the application and generates multi-threaded code that is transportable across multiple architectures, eliminating the need to rewrite application code for individual multicore computing systems.

ThreadedS uses a simple process to accelerate existing applications for multi-core

Step 1: The customer designs their application in normal engineering terms and formulas

Step 2: TMT writes portions of the application in SequenceL and confirms the application performs as designed

Step 3: The customer may read and audit the SequenceL code

Step 4: TMT compiles the application to parallelized C++ and ensures optimized performance

Step 5: The application is delivered to the customer development team for integration into the customer's application or system

ThreadedS Features

Fastest path for upgrading existing software to multi-core & many-core

Delivers parallel, multi-threaded C++ code

Increase application performance and capability

Reduce compute time

Reduce energy costs and improve carbon footprint

Optimized investment in parallel code development

Fixed-fee engagement, avoids costs of repeated manual parallelization efforts

Frees internal software developers to focus on core application features

Provides extensive testing and debug of application performance

Produces reusable and transportable parallel code

Expert services for parallel code optimization

Parallelize just the sections of an application with most of the processing load

Build improvements into the application while adapting to multi-core

Design in new features optimized for parallel processing

Uses SequenceL compiler and parallelized math libraries

ThreadedS Benefits

Delivers outstanding multicore performance

Reduces development costs

Enables integration of parallel code into existing applications

Shortens time-to-market for multicore performance

Eliminates the risk of multicore migration

anyways, I will so no more on the topic :) as i said the die is cast and things are what they are :)

[dav 22]

Using Msi I capped my fps at 30: view distance 2k and textures ultra, I get 30 in most situations within reason. The thing is on the dev build frames just drop from 30 to 29 no matter what. Even if I set it for 60fps it drops to 59 etc..

[mt 10]

Currently, my imaginatination of the (client-side) engine code is like this:

Thread1() {

while(true) {

ExecuteAllScriptsPendingToTheirEnd();

CauseAIToMakeSuperIntelligentDecisions();

PlanAllAIPathsOnMap();

ApplyStateChangesOnAllEntitesOnMap();

InPartiularMoveEveryBladeOfGrassInTheWind();

SendTheResultToGPUToLetThePlayerSeeAnotherFrame();

}

}

Thread2() {

// generate core load to simulate multithreading capabilities

while(true) {

sleep(60% of the time); // but not too much, people could get suspicious

}

}

Is this a plausible assumption?

[daze23 1]

things had gotten sort of manageable on Stratis, but Altis has made these issues apparent again. it seems like performance gets worse over time on Altis. it's not just AI, cause I can get crap frame-rates just standing in an empty town. but yeah, AI and scripts on top of that makes things worse

[mobile_medic 43]

Please just don't go down the road of thinking this is a multiplayer only problem. I don't even play multiplayer b/c of how bad it is. Almost all of my input into this thread has been with regards to single player performance.

Thank you for providing some input into this thread. You mentioned previously that you had found some problems with the engine. can you, perhaps, give us some info as to what you've found and at least what a plan of action is. No one who has been following this issue has the expectation that it is a quick fix issue. in fact, we are quite aware that this is a core issue with the game. So, any kind of info as to a roadmap or what kind of improvement would be considered realistic would be very helpful. b/c as it is now, I can do very little beyond the scope of very small encounters.

Objects are first and most reproduce-able impact-er of gpu usage and fps before we even get into adding ai, etc.

[daze23 1]

Please just don't go down the road of thinking this is a multiplayer only problem. I don't even play multiplayer b/c of how bad it is. Almost all of my input into this thread has been with regards to single player performance.

I like how they count on the community to generate multiplayer content, and then blame the community for bad performance in that multiplayer content. maybe they could provide us an example of multiplayer content that does run well

anyway, I agree that 'objects' seem to be the main problem, and other issues compound on top of that. performance is pretty good when you're away from any buildings, but things go downhill quick when you get near a town/village

[Whispy 10]

My FPS is generally around mid 30s, but when I play for ~45 minutes to an hour, my FPS will suddenly drop to around 10 when I look around or press any keys. However, if I don't press a key or look around, it will go back to normal (but it resumes if I press a key/look around).

Today, I decided to record the CPU usage and memory using Performance Monitor. Here is what it looked like (the FPS dropping starts to happen at 2:14:35 PM):

The 'IO Read Operations/sec', 'Cache Faults/sec', and '% Privileged Time' all shoot up VERY high, while '% Idle Time' and '% C3 Time' both take a very steep drop. Afterwards, the log looks like it goes back to normal, but the FPS drops in-game still continue until I restart my client.

Specs:

Intel Xeon E3-1230v2

GTX 570

16 gb RAM

Win 8 64-bit

EDIT: This occurs regardless of the mission I'm playing.

Edited September 1, 2013 by Whispy

[Drumheller 19]

My FPS is generally around mid 30s, but when I play for ~45 minutes to an hour, my FPS will suddenly drop to around 10 when I look around or press any keys. However, if I don't press a key or look around, it will go back to normal (but it resumes if I press a key/look around).

Today, I decided to record the CPU usage and memory using Performance Monitor. Here is what it looked like (the FPS dropping starts to happen at 2:14:35 PM):

http://i.imgur.com/7EAX8X4.png

The 'IO Read Operations/sec', 'Cache Faults/sec', and '% Privileged Time' all shoot up VERY high, while '% Idle Time' and '% C3 Time' both take a very steep drop. Afterwards, the log looks like it goes back to normal, but the FPS drops in-game still continue until I restart my client.

Specs:

Intel Xeon E3-1230v2

GTX 570

16 gb RAM

Win 8

EDIT: This occurs regardless of the mission I'm playing.

I am experiencing this exact same issue.

[204 Kallisto 14]

i have exactly the same problem also in ArmA3 as well as in arma2

[griffz 1]

and hopefully it will help you to get better performance as well.

Radeon 7950 3gig/ 16 gig ram / 3.1 ghz 8120 amd 8 cores

thanks sir. but without too much of pessimism , we all agree there is a major bottleneck, somewhere else, during MP game. it is NOT related to HARDWARE.

About graphics settings, it's very eay too have 100% GPU load during MP phase. simply crank up every "gpu related" parameter.

we all agree here, that bohemia will need to do something about it. it's like arma lost its ability to simulate large scale battelfield.

Edited September 1, 2013 by griffz

[tvamvarg 0]

I've searched and browsed threads for a half hour now, can't find anything related so I'll ask here:

I've got a low-end rig, but it ran fine on Stratis. But Altis is a totally different story. FPS drops to 1 after a while and basically the game crashes. No MP, no AI (I just placed myself in the editor). On Stratis, I can play with serious amounts of AI, and I've also played MP (though not on latest release). I'm on dev branch. It's not a view distance issue as I can pull it down to minimum and it doesn't matter.

I can see the difference just going into the map ingame, the loading of the map when on Altis is visibly laggy - so I assume that this is related.

Is there anything I can do? It seems to me that I should be able to play on Altis as well as on Stratis, when I have the small view distance anyway. It should also not be a memory issue, I have 4 GB (hey I said it was low-end!) on a 32-bit Windows 7.

Maybe someone can point me to an existing post that discusses this, I'm sure there are quite a few, I just couldn't find them...

[Whispy 10]

I am experiencing this exact same issue.

I've run into a few people here and there who also have this issue. I'm not sure what's causing it, but I hope someone can take a look at it!

[griffz 1]

32bit is not recommended for arma3.

[Sneakson 1]

I've searched and browsed threads for a half hour now, can't find anything related so I'll ask here:

I've got a low-end rig, but it ran fine on Stratis. But Altis is a totally different story. FPS drops to 1 after a while and basically the game crashes. No MP, no AI (I just placed myself in the editor). On Stratis, I can play with serious amounts of AI, and I've also played MP (though not on latest release). I'm on dev branch. It's not a view distance issue as I can pull it down to minimum and it doesn't matter.

I can see the difference just going into the map ingame, the loading of the map when on Altis is visibly laggy - so I assume that this is related.

Is there anything I can do? It seems to me that I should be able to play on Altis as well as on Stratis, when I have the small view distance anyway. It should also not be a memory issue, I have 4 GB (hey I said it was low-end!) on a 32-bit Windows 7.

Maybe someone can point me to an existing post that discusses this, I'm sure there are quite a few, I just couldn't find them...

32-bit + Altis is currently causing issues for most people so don't worry about there being anything wrong with your computer.

32bit is not recommended for arma3.

It is also not not recommended FYI.

[tvamvarg 0]

32-bit + Altis is currently causing issues for most people so don't worry about there being anything wrong with your computer.

It is also not not recommended FYI.

Thanks! I'll keep my cool then.

I set this rig up just for Arma 2 and 3 actually, and though about the 64/32 version choice, but found nothing that said that 64 was preferred, rather the opposite (nothing in System Requirements either on Arma 3 site or on Steam... are these official or non-official recommendations?). Oh well, I'll have to set up a 64 version maybe instead if things don't improve.