CPU Utilization... Again.

[BitMaster]

I just loaded an included Ka-50 mission and just let it run, when the tanks and armor got involved my CPU went 60ish to a peak of 88% load.

 

 

Dunno, heck, that's what mine says and does..and it chews through it

[Chic]

I think there's a number of misleading terms being thrown about.

 

 

DCS as an application doesn't utilize two "cores" per se, but rather two execution threads. As to how many cores are assigned to to run those two threads, that is a function of the operating system.

 

 

The OS scheduler is responsible for ensuring those two threads can run as quickly as possible, and that can result in the thread hopping cores constantly, as someone in this discussion pointed out. Remember that not every execution cycle is necessarly devoted to performing a function that results in updates to the state of the simulation. It takes clock cycles to clear registers, load data into cache, load instructions, etc. If a given operation, which may consist of 10-30 steps (this is a sample figure pulled out of the air), and the core is "cleaning up", then the OS can send an operation to another core provided requirements are met. But it doesn't mean there's an implicit parallelism where there wasn't one.

 

 

When we talk about making DCS multi-threaded, we the players are usually referring to the core physics engine, and from my admittedly outside perspective, I can see where that would be an enormously difficult lift with little potential payout. So much of the simulation is dependent operations occurring in order that I'd be skeptical as to how much of the work can be made parallel. Trying to merge parallel threads to reassemble order would likely impart so much latency, both in pauses needed and for the additional overhead needed for the orchestrater to reassemble the stream that whatever performance gains there were would likely be erased. It becomes an issue of diminishing gains, and I've seen this with other applications. This is one area of computing where raw, single-threaded performance wins out.

 

 

 

For aspects like sound, some graphics, and clients, where there aren't such time-bound dependencies, splitting these functions off can be easier, and that's exactly what I imagine DCS is doing when they've said they're removing graphics from the upcoming dedicated server. It removes a big source of CPU usage at minimal labor cost.

 

 

If you want to see another case of a similar issue in gaming, consider digging through EVE Online's old DevBlogs...they've been battling a similar issue for years, stripping as much as possible from the simulation thread so it gets as much CPU time as possible.

 

 

A challenge, to be sure.

 

 

Enlightening. Thank you.

[DflippinK]

Nothing anyone has said here is incorrect... not as far as task scheduling, the way the game is actually composed of two "execution threads", or or weather or not those two "execution threads" can be processed by more than two cores... all of these things are true and always have been... the purpose of this was to bring attention to the fact that "we can" offload some of what the primary core often gets saturated with to another core therefore increasing its headroom and avoiding full core saturation.. obviously we can not break up the physics engine... but we dont have to... the system runs flawlessly with approximately 20% of the primary cores "execution thread" diverted to a different core..

[Pikey]

Whilst the "execution thread" post was the best attempt at explanation so far, I cannot agree completely that there is not some misunderstanding in this post on why CPU's show what they do. I'll add to where there could be improvements and use real world examples.

 

 

The easiest way of "black box" explaining, is to look at another infantry simulator sim that has way more money to throw at the problem and is in the same boat. In that sim they designed an offload process to help their main thread not get so caught up in loops inside the main thread, so they offloaded AI processing to it. It has marginal benefit, more at high unit counts and less at low level. You can add these headless clients to their dedicated server as many as you like. Simple fact is there is always a main thread in any application and if things need to run in order, it has to fit inside it. You can implement asynchronous timed FSM's or offload things that do not need to be processed in sync, but you cannot magically untangle things quite as easily as everyone seems to think.

 

 

 

How about the 'space game' that has millions of dollars available and vast teams and resources? Runs like a dog. A three legged one at that.

 

 

 

There are things that can be unpicked from the main thread, DCS does it with sound. There may be more it can do, at great developer time expense later. And of course there is optimisation, which has laws of diminishing returns. Right now you can see those diminishing returns in action as you add more and more unit counts, especially planes and detectors. This is the area I see an asynchoronous execution thread being of value, in AI, just like the other sim that does it. But it's going to be a lot of work, we aren't even at dedicated server stage and the first iteration is not going to be a real dedicated server, it's just a GFX headless client with a web front end for control, it's not going to be the silver bullet that everyone thinks/hopes it will be.

 

 

 

 

In the short term, if you want to see an improvement, it means dipping in your pocket. The largest single improvement in DCS performance is an Intel Coffee Lake CPU. When I upgraded from an OC'd 2500K at 3.5 and went to a 8600K at stock CPU, my FPS soared by ridiculous factors, especially under load in more complex missions. If this is your hobby, and you are serious, it's a way better spend of your time than writing in the forums.

 

 

 

 

I'd like to hope DCS will move to offloading AI processing at some point. Especially the non realtime and costly detection calculations, the transport routing, the AI combat scripts. I still see a permanent issue with the EVENT system which will likely remain synchronous in the main application thread, the actual Flight models have to be in the main thread and likely most of the game, but of course there are possibilities.

 

 

 

 

At the current rate of development, I wouldn't be sitting hoping though. TBS is rated for 32 players based on the marketing blurb on its web page, and we are the testers for it, and have been, for many years.

 

 

Nothing anyone has said here is incorrect... not as far as task scheduling, the way the game is actually composed of two "execution threads", or or weather or not those two "execution threads" can be processed by more than two cores... all of these things are true and always have been... the purpose of this was to bring attention to the fact that "we can" offload some of what the primary core often gets saturated with to another core therefore increasing its headroom and avoiding full core saturation.. obviously we can not break up the physics engine... but we dont have to... the system runs flawlessly with approximately 20% of the primary cores "execution thread" diverted to a different core..

[melchionda]

Interesting conversation. So is the conclusion that we should turn Hyperthreading off? I'm running an Intell Core i7 990X processor.

[mastershotgun]

Honestly, I would not do that... The reason is that ED know that they are not utilizing CPU nominaly at the moment and they are working on improving it... Wait for their new renderer engine for example, it should do much better job and not even mentioning that when they finaly switch to vulcan, which scales much better with cores than enuthing else, you will see improvements...

[javipamp]

any information about vulkan update?

 

Hi. I'm supporting DCS because ED said, long time ago, it would support vulkan. Many of us would like to know how the task is going and when more or less would be ready the first beta. We've been waiting too long without any news. Many thanks and keep pushing.

[RealDCSpilot]

@DflippinK

 

a bit late to the party, but dropping GPU load on purpose is not a good thing. You want your GPU usage always at the highest level as possible. It says "i'm making the most out of it.." in a CPU bound scenario like DCS. In your case, 60% could mean that there is enough headroom to not downgrade visuals with the shader mod and even maybe choosing higher options for better visuals in graphics settings OR your CPU is too weak to deliver data fast enough to the GPU.

[Worrazen]

Oh, guys, that's an old thread you found there, it's a bit more complicated, it's not like that as it seems in task manager, it's not using just 2 or 3 cores, but a lot more infact, however indeed 2-3 threads are the most important ones.

 

You could search threads/posts for terms like "threads" and "core" and include filter with my username, should get you more details.

[CAmastersgt]

At this point I'm waiting for "Vulcan" to release their own flight sim. LOL

 

The new GPU's should help in the near future, if we can afford them. The future looks promising.