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

[Sheepherder]

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?

 

Let's say AI and physics are on separate cores, since it illustrates the problem.

 

There's a big do over Novorossysk, with a few flights of F-86s escorting a couple of B-52s while they pound multiple layered SA-3 and ZU-23-2 sites. The physics core is chirping along merrily, since it's mostly the simple flight model, cannon shells, and missiles. But the literal hundreds of units attempting to engage the aircraft are causing the AI core to choke.

 

What happens? Do the US aircraft stop dodging easily avoided missiles and start slamming into mountains because they only get an AI update every few seconds?

[112th_Rossi]

Cores have nothing to do with threads.

 

Please for the love of God stop confusing the two.

 

You can multi-thread on a single core if you want. Cores help to spread processing load horizontally across the CPU instead of having to ramp up the clock speed to do the same job.

 

The DCS.exe process has one main thread and that executes top to bottom. If you want to multi-thread you must decide what parts of the process can be done asynchronously without affecting the overall processing chronology. Some routines must be executed in order while others can execute at anytime.

 

It's not as simple as it sounds and depends on how tied together many of the routines are. You can open up a can of worms in terms of memory access since you are no longer just adding to a heap. Memory must be managed in such a way that async rountines don't conflict with each other. In managed code like C# that's easy as it's all taken care of (look at Task Parallel Library) while in C++ an appropriate memory manager must be employed to marshal read/writes.

 

That said there are few quick wins with threading. Loading of resources, such as textures and models can be done asynchronously, that is, the system can load up many resources at the same time instead of one after the other. Also, it could be possible to load assets during the game on another thread as to reduce load in stutter. The downside of this is that assets may not appear at exactly the right time and you may get pop-ins. This is the nature of the async beast. You must identify what routines are ok to siphon off to be async.

 

Lets be clear though, threading has nothing to do with cores. At all. It's a programming technique and this technique is architecturally independent.

[Aginor]

Cores have nothing to do with threads.

Please for the love of God stop confusing the two.

 

It doesn't matter. Having threads run on different cores has advantages, everyone has a multi-core CPU, and it is good practice to have threads running on different cores, which is what systems try to do. Yes, it is not the same, but it really doesn't matter.

 

People not understanding multi-threading won't understand it more easily if you get one level of abstraction more into it. Let's just pretend every core can do one thread, it is absolutely sufficient to explain the problems with multiple threads AND/OR cores.

People look at their four cores and wonder why only two of them are doing something, they don't see the threads.

 

So with all due respect, all of what you just wrote is completely undecipherable for someone who is not a programmer. That's exactly why we are doing simple examples here. :)

[SkateZilla]

Cores have nothing to do with threads.

 

Please for the love of God stop confusing the two.

 

You can multi-thread on a single core if you want. Cores help to spread processing load horizontally across the CPU instead of having to ramp up the clock speed to do the same job.

 

The DCS.exe process has one main thread and that executes top to bottom. If you want to multi-thread you must decide what parts of the process can be done asynchronously without affecting the overall processing chronology. Some routines must be executed in order while others can execute at anytime.

 

It's not as simple as it sounds and depends on how tied together many of the routines are. You can open up a can of worms in terms of memory access since you are no longer just adding to a heap. Memory must be managed in such a way that async rountines don't conflict with each other. In managed code like C# that's easy as it's all taken care of (look at Task Parallel Library) while in C++ an appropriate memory manager must be employed to marshal read/writes.

 

That said there are few quick wins with threading. Loading of resources, such as textures and models can be done asynchronously, that is, the system can load up many resources at the same time instead of one after the other. Also, it could be possible to load assets during the game on another thread as to reduce load in stutter. The downside of this is that assets may not appear at exactly the right time and you may get pop-ins. This is the nature of the async beast. You must identify what routines are ok to siphon off to be async.

 

Lets be clear though, threading has nothing to do with cores. At all. It's a programming technique and this technique is architecturally independent.

 

Generally 1 Core = 1 Thread,

Unless the Core is designed to have Simultaneous Multi-Threading, In Which case it can Process 2 Threads On 1 Core.

 

I think you mean Cores have nothing to do with Processes.

 

 

Multi-Threading on a Multi-Core CPU allows tasks to be processed in parallel (at the same time)

Multi-Threading on a SingleCore CPU processes one task, suspends, processes the second, then comes back to the other task, which would show Zero Benefit over a Serial Task, and likely make it slower.

Edited August 12, 2016 by SkateZilla

[cichlidfan]

How cores, threads and processes relate is mostly irrelevant to the conversation. The issue here is the OP's inability, or unwillingness, to appreciate the amount of work involved in rewriting an existing large application to make use of multi-threading. Along with the amount of work, the other issue is the significance, or lack, of any performance gains.

 

What goes on under the hood doesn't need to be delved into in order to examine the primary issue.

[112th_Rossi]

Generally 1 Core = 1 Thread,

Unless the Core is designed to have Simultaneous Multi-Threading, In Which case it can Process 2 Threads On 1 Core.

 

I think you mean Cores have nothing to do with Processes.

 

 

Multi-Threading on a Multi-Core CPU allows tasks to be processed in parallel (at the same time)

Multi-Threading on a SingleCore CPU processes one task, suspends, processes the second, then comes back to the other task, which would show Zero Benefit over a Serial Task, and likely make it slower.

 

My point was that you don't need cores to multithread. Modern CPUs are adapted for threaded operations but the assertion (if there is one) that you need multiple cores for multi threading is false.

[firmek]

How cores, threads and processes relate is mostly irrelevant to the conversation.

To some extend however the discussion shows how much complex the topic is and how far away from understanding this fact we are. The problem is not really the technical capabilities of a programming language or constructions aspects of the processors. Multithreading (multi-tasking) is a domain of knowledge on itself. Concepts and problems related to it have been research long before multi-core processors. I would like to suggest that before making strong claims about “it's easy" try investigating into basics of the domain. In this specific case this could be the consumer-producer problem, semaphores, solving TSP problem by using multi-tasking approach with a pen and paper and then maybe by implementing it with programming language that doesn’t do everything for the programmer behind the scenes. Only when knowing the concepts and challenges that concurrency and multithreading creates a discussion about complexity and putting the solution into perspective of any specific technology should be carried out.

 

The issue here is the OP's inability, or unwillingness, to appreciate the amount of work involved in rewriting an existing large application to make use of multi-threading. Along with the amount of work, the other issue is the significance, or lack, of any performance gains.

 

What goes on under the hood doesn't need to be delved into in order to examine the primary issue.

It takes a lot of life real life experience with big systems to understand and appreciate the challenges related with the overall lifecycle of the application. We're not dealing with a new system. It's not “only” a task of defining the scope, designing a new application and then developing it. Even putting the multi-tasking aside for a while, introducing changes to a existing system is usually not trivial task while the complexity and so do required effort increase with their age.

Features like support for multi-threading should be considered as a design critical. If not taken into consideration at the very beginning and if have to be introduced later, quite often the only reasonable decision that is left is to redesign and rewrite the whole system. Then however it’s most often not suitable at all from the business perspective and it’s better not even to start discussing it without having critical gains (scope changes) on the horizon.

[cichlidfan]

My point was that you don't need cores to multithread. Modern CPUs are adapted for threaded operations but the assertion (if there is one) that you need multiple cores for multi threading is false.

 

Which still has nothing to do with what is being discussed. Where the threads are in the hardware doesn't matter one single bit.

[Sheepherder]

Generally 1 Core = 1 Thread,

Unless the Core is designed to have Simultaneous Multi-Threading, In Which case it can Process 2 Threads On 1 Core.

 

I think you mean Cores have nothing to do with Processes.

 

Multi-Threading on a Multi-Core CPU allows tasks to be processed in parallel (at the same time)

Multi-Threading on a SingleCore CPU processes one task, suspends, processes the second, then comes back to the other task, which would show Zero Benefit over a Serial Task, and likely make it slower.

 

No, he is correct. A process is an instance of a program, a thread is a slice of the program that can run independently of the whole, and a core is the metal.

 

There actually is an advantage to threading on a single core - remember that the various caches and and system memory operate at progressively higher latency and lower bandwidth the further you get from the core. A single core operating a single thread will be sitting idle waiting on memory read/write for a good portion of the time unless it can queue threads and rapidly switch.

Edited August 13, 2016 by Sheepherder