Why one thread (on 4 core/8 thread CPU) 90% usage while others only 10-30 % ?

[D4n]

Will there be a patch in near future to balance DCS load on 4 cores/8 threads more equally?

[SkateZilla]

No,

 

This has been Covered Over and Over again,

 

Search Function "Multi-thread"

[D4n]

I searched but couldn't find a statement from an ED developer in the 56 results about when it will be patched and why DCS is using one core (thread in this case) HEAVILY (90%) and the other 4 cores/7 threads only 5-20/30 %... ?

[SkateZilla]

Apologies I think the original thread, where a developer did respond (one of the EDGE Threads) has since been deleted.

 

Long story Short, it's Not in the Immediate Plans.

[D4n]

Do you remember anything from what the developer's reply contained? (any content he stated?)

 

Cause Dx11 itself distributes the code well enough to 8 threads (or alone 4 cores) generally right? I think it is that one major task of DCS is done on that one 90%-load-core/thread, which could be split by splitting the code to more threads?

 

I think it is related to the mirrors on the aircraft, couldn't the mirrors be split (2 threads/1 core calculate left mirror, 2t/1c the top mirror, 2t/1c the right mirror on MiG-29S as example) ? :) I think we found a solution!

Edited July 29, 2016 by DanielNL

[Knock-Knock]

It is far more complex than just pick and choose what you want to run on this and that core. Everything is intertwined like you wouldnt believe, and just splitting that up, so it works in parallel on multiple cores/threads, is a huge task. Then add to that it has to scale. Run 2 cores, 4 cores, 8 cores etc etc etc.

 

If it was like picking items of a shelf, you can be sure ED would have done that a long time ago already.

[Buzzles]

Daniel, with all due respect, it's clear you don't know much about multi-threading and parallel programming. Might be worth going off and doing research.

 

Long story short, more cores != more performance all the time. DCS (like most games) are one of those times. You can't just split processing into parallel threads when a lot of the work has to be done sequentially.

In order to do it you generally have to have to build an application around that notion from scratch, and even then, it can be very hard to do and some stuff you simply cannot run in parallel.

Topics of interest: Thread Waiting, Thread Synchronisation, Deadlocks.

 

Currently, DCS runs on 2x cores for the main application (core app on one, sound on another) and has done for years. The EDGE upgrade (ED Graphics Engine) which was implemented with 1.5/2.0 has shoved a lot of work onto the GPU, so just looking at your CPU usage isn't a clear cut sign either, and part of the EDGE upgrade was to decouple the renderer from the logic code.

ED are making progress towards performance, and they're in a quite a good place right now.

Edited July 29, 2016 by Buzzles

[D4n]

... and just splitting that up, so it works in parallel on multiple cores/threads, is a huge task. Then add to that it has to scale. Run 2 cores, 4 cores, 8 cores etc etc etc.

 

But (afaik?) in the program code it could be added (basic language here):

 

"if 2 cores = split up all program parts into 2 groups"

"if 4 cores/threads = split up all program parts into 4 groups"

"if 8 cores/threads = split up all program parts into 8 groups"

 

so that specific program parts are run only on the appropriate CPU core count systems?

 

(Who is playing DCS on dual core system anyway in the days of cheap quad core CPUs right?!)

 

 

You can't just split processing into parallel threads when a lot of the work has to be done sequentially.

 

Why not? What would theoretically/practically happen in DCS if it is written like "to first part of sequence on core A" and "2nd sequence part on core B" ?

 

it can be very hard to do and some stuff you simply cannot run in parallel.

 

Like which things? (Why wouldn't specific things run parallel?)

 

Topics of interest: Thread Waiting, Thread Synchronisation, Deadlocks.

 

So I will google these topics, alright... (never heard the word "Deadlock" btw!)

 

 

Currently, DCS runs on 2x cores for the main application (core app on one, sound on another) and has done for years.

 

Then the question which things are on core app... Like couldn't all flight model physics calculation be done on 1 core/2 threads and all other things on different cores/threads?

 

And about sounds, couldn't they even be split further, like only play (for example) max. 5 specific sound effects simultaneous on core/thread X and play all other sounds that run on that moment on core/thread Y... :) ? (so all threads evenly loaded with sound effects?)

 

 

ED are making progress towards performance, and they're in a quite a good place right now.

 

They're in a quite a good place right now, of course! :) (But still I am surprised that one of my threads goes 90-100% in DCS...)

 

I wasn't looking at my CPU alone, I've looked into GPU, which shows me around 30-70% usage most of the time, and only few seconds every once in a while in DCS it spikes to 99%...

 

 

And then the question remains how much the current progress is from moving the Caucasus to DCS 2.0... :) (which will make it more beautifully and less CPU intense at same time iirc?)

[SkateZilla]

To be honest, the Biggest performance gain will be when the DirectX kernel and commands are no longer processed by the CPU but instead sent directly to the GPU,

 

And that would require a DX12 Engine, which is not happening anytime soon.

[D4n]

Is it that hard to "convert" the Dx11 files into Dx12 ? (or how does such a "conversion" work?)

 

Though it would be cool in the future to have DCS detecting on game launch if user has Win 10 and Dx12 capable GPU and then run game in Dx12 (else 11) :)

[StandingCow]

I know there are no plans for the client... wonder if the dedicated server, once it comes out, would support multi threads?

[D4n]

Wait, standingCow, how much load does one server CPU currently have (on quad core server) ?

[StandingCow]

Wait, standingCow, how much load does one server CPU currently have (on quad core server) ?

 

Don't know, I don't run a server. ED mentioned they are eventually going to support dedicated servers, but right now the client only supports 1 core (sorta 2 I guess since sound is on another core).

 

But I was curious if dedicated servers will be any different as far as supporting multi-cpu cores, I guess we will have to wait and see.

[D4n]

Well there IS Lua Lanes... :) http://lualanes.github.io/lanes/

 

So Lua is a safe future for DCS after all (right?) !

[NeilWillis]

Take a look at how long took to migrate the code from DX9 to DX11.

 

Easy in theory perhaps, but in practice, it is incredibly involved, especially when we are still waiting for the EDGE project to be completed still, and will be until probably the end of the year.

 

So, to answer your question, no, don't hold out hope for this, at least not this decade!

[Aginor]

I agree with NeilWillis this time.

Sure sounds nice but nobody can tell what side effects it could have. I wouldn't get my hopes up for it being implemented any time soon.

[sobek]

But (afaik?) in the program code it could be added (basic language here):

 

"if 2 cores = split up all program parts into 2 groups"

"if 4 cores/threads = split up all program parts into 4 groups"

"if 8 cores/threads = split up all program parts into 8 groups"

 

so that specific program parts are run only on the appropriate CPU core count systems?

 

You aren't even scratching the surface of the problem. This is way too superficial.

 

Why not? What would theoretically/practically happen in DCS if it is written like "to first part of sequence on core A" and "2nd sequence part on core B" ?

 

It would run slower than if you'd execute it on one core. There are sequences in the code that can not be parallelized. To put it in simple terms, think of an algorithm as a sequence of a few mathematical operations. You can't perform the last operation before you have the result of the ones that precede it. It is simply not possible because of causality.

 

There are other scenarios where it might be possible, but the time needed to realize it is prohibitive.

 

Like which things? (Why wouldn't specific things run parallel?)

 

Because for example they depend on results of other operations. If you split something into a second thread and that thread is going to sit there idling while the first thread needs to finish, you just effectively wasted precious worktime on something that actually worsened the execution speed of your program.

 

Then the question which things are on core app... Like couldn't all flight model physics calculation be done on 1 core/2 threads and all other things on different cores/threads?

 

Define "things". AI, maybe. Sound is already there. If by things however you mean other physics simulation topics then the answer is most likely no. The physics engine in DCS is, as far as i can gather, real time in the scientific sense, that is, frames need to be finished in a predetermined amount of time or bad things start to happen. That alone is very hard to achieve with a multithreaded application. When you factor in the level of dependency between all things physics, you end up in a place where multithreading won't do anything for you.

 

And about sounds, couldn't they even be split further, like only play (for example) max. 5 specific sound effects simultaneous on core/thread X and play all other sounds that run on that moment on core/thread Y... :) ? (so all threads evenly loaded with sound effects?)

 

What would that achieve? The sound engine isn't the bottleneck, it's not even close to running into performance problems. Besides if you split everything into threads until you are at atomic operations, you will have so much overhead that you are once again running slower than without splitting it up. Having more threads than cores can be beneficial, but it can also hurt you.

 

Well there IS Lua Lanes... :) http://lualanes.github.io/lanes/

 

So Lua is a safe future for DCS after all (right?) !

 

No. The performance critical stuff doesn't run in lua. lua isn't meant for heavy lifting. That's what C++ is for.

 

The bottom line is, this is an incredibly complicated topic (and by incredibly complicated i mean that some of the smartest minds in computer science are baking their noodles about it). If you really want to understand why multithreading is so complicated (and i mean *really*), learn a programming language and do a tutorial that teaches you to program a basic multithreaded application.

[D4n]

I learned Java at school and now I'm learning Python on codecademy.com, but there is no C++ there sadly... And there doesn't seem to be "multithreading" topic in the tutorials... :/

 

https://www.codecademy.com/learn/python

 

https://www.codecademy.com/learn/learn-java

Edited August 1, 2016 by DanielNL

[Aginor]

Multithreading in Java is rather easy, but it gives you a good idea about the added complexity for handling several threads.

 

Just a small dip into that:

http://www.tutorialspoint.com/java/java_multithreading.htm

[sobek]

It's really easy if you have processes that aren't coupled at all. E.g. at work we do processing of sensor data. A sensor sends data and the server processes the incoming data and puts the results into databases. This is perfectly parallelizable. Each sensor that sends new data gets added to a queue. Once a CPU is free, the uppermost sensor in the queue is assigned to a worker that performs all tasks necessary for that sensor. Voila, you can easily scale that to as many CPUs/servers as you have available (with some limitations depending on the database interface, but that's the details).

 

The problems start appearing once the threads need to talk to each other. With DCS, there are a lot of components that are tightly coupled, not just because they were programmed this way but because they depend on a lot of data from other components. That is the reason why the splitting up part is very hard.

 

As previously mentioned, there may be components that can be pulled out because they can be made to run asynchronously. This in itself is usually a big task however. The only component that runs in a separate thread, the audio engine, only does so because at some point it was pretty much written from scratch (IIRC), at which point it was feasible to write it threaded. I imagine the same could potentially happen to other components, under the premise that they can be pulled out of the core engine thread without needing to communicate to the core too much.

Edited August 2, 2016 by sobek

[D4n]

Multithreading in Java is rather easy, but it gives you a good idea about the added complexity for handling several threads.

 

Just a small dip into that:

http://www.tutorialspoint.com/java/java_multithreading.htm

 

Thanks will look into it. And can a Java thread consist of multiple Java classes or just a single one?

[Aginor]

Java is a monster, you can create all kinds of silly stuff, including inner, anonymous classes (*shudder*). I stopped working with it years ago so I really can't say, sorry.

 

@sobek: That's exactly what people tend to not fully understand. The problem isn't making the threads, the problems are that some stuff just can't be done parallel, inter-thread communication is a nightmare to debug and can cause stuff to actually run _slower_ than doing the same single-threaded, and pulling functionality out of the structure and implementing them in another thread is a ugly task. In many cases you would rather write it completely from scratch before doing that.

Edited August 2, 2016 by Aginor

[D4n]

So there ARE easy ways to do it!!!

 

https://en.wikipedia.org/wiki/Automatic_parallelization_tool

 

https://en.wikipedia.org/wiki/OpenMP

 

http://openmp.org/wp/openmp-compilers/

[Buzzles]

None of those are "easy".

 

As you still haven't taken on board what we've been saying:

 

Writing an application to use threading is straight forward. There are tools, as above, which can help. It's actually pretty easy to wrap function calls up in threads. C# world is really really easy with the Task feature set.

 

Writing an application that actually:

Runs without crashing

Doesn't give batshit crazy outputs

Actually runs *faster* than when it was single threaded

 

That is actually really bloody hard for non-trivial applications.

Edited August 8, 2016 by Buzzles

[Aginor]

I think the "cake example" fits here rather well:

 

Imagine you have a program that can bake a cake. It does the following steps:

1 heat the oven (5 min)

2 prepare the ingredients for the dough (10 min)

3 create the dough from the ingredients (10 min)

4 bake the cake (30 min)

5 prepare the frosting (5 min)

6 apply the frosting (10 min)

7 decorate the cake (5 min)

 

All in all: 75 minutes of work.

It runs single threaded, everything is done one at a time.

 

Now let's change it to multi-threading. YAY! Let's see:

 

1 can be done while 2 and 3 are running

3 waits for 2

4 waits for 3

5 can be done while 1,2,3,and 4 are running

6 waits for 4 and 5

7 waits for 6

 

You have four cores so you could theoretically do four simultaneously.

So you can erase the time for..... 1 and 5 actually. That's it.

 

So while multithreading may seem like you can get those 75 minutes down to 40 minutes, you can actually only reduce the workload by 10 minutes and you have never more than two cores running. BUT you have a huge organization overhead (the cores have to talk to each other) and have to re-write all your code. It isn't worth it.

 

I hope this simplified example makes the problem a bit more clear. :)