Uses only 1 core of multicore processor?

[Farradin]

I get a random crash. I thought maybe it was heat related. Starting monitoring heat. Nope. No heat issues. I did notice that the game only uses one of the cores at about 27%. I have a AMD Ryzen 9 16 core 32 processes CPU. One of the best. Is that normal?

[Die Hand Gottes]

Origineel geplaatst door Omega420:

If your using software to force the game to run on all cores, your undermining AMD's Zen algorithm's along with windows task scheduler.

Forcing all your cores to work on something that doesn't require all cores results in your cores running at or near max speed causing unnecessary heat.

Do not use AMD have never used AMD stay with Intel that already for about 40 years and with me nothing is hot
Have my temperatures also in the keyboard in view and as you see in the picture there is also nothing hot displayed
Normally the games are used with me anyway with all cores why not the fewer cores the worse run the games

[Omega420]

Origineel geplaatst door Die Hand Gottes:

Origineel geplaatst door Omega420:

If your using software to force the game to run on all cores, your undermining AMD's Zen algorithm's along with windows task scheduler.

Forcing all your cores to work on something that doesn't require all cores results in your cores running at or near max speed causing unnecessary heat.

Do not use AMD have never used AMD stay with Intel that already for about 40 years and with me nothing is hot
Have my temperatures also in the keyboard in view and as you see in the picture there is also nothing hot displayed
Normally the games are used with me anyway with all cores why not the fewer cores the worse run the games

OP is using a Ryzen 9 and yes I am using a Ryzen 7.

While I admit I'm not sure about Intel fully. I do know their newer chips with E / P cores is basically trying to do the same thing Ryzen CPU's are trying to do which is being smarter on how tasks are processed. When to speed up the clock for a certain operation and what not.

Even on Intel forcing a program to use all cores instead of letting the CPU's logic and Windows task scheduler handle core utilization in my experience and from posts on the internet over the years will almost certainly lead to worse performance and even crashes.

Random example off the top of my head... Cyberpunk 2077 at 4K RTX Performance...

On AMD Ryzen CPUS. You will notice that your best cores will always have higher utilization and a higher core clock then the worst cores. This is because the CPU is deciding how to best manage the Cyberpunk task for best performance. Just like the CPU through it's own internal tests has decided which cores run the fastest and which ones run the slowest.

If I force CP 2077 to run on all cores, the CPU's performance will be limited by the weakest cores which can't clock as high as your best cores.

Sure all your cores are being used but they are now running slower and could be using more power then need be since the worst cores need more power to reach it's max clock.

Intel CPU's with E / P cores have the same logic. Why force all your E and P cores to run full speed or at the very least faster then then need to when say only 2 P cores are more then enough.

Even if there is no noticeable temp increase, your still putting potentially unnecessary wear on the silicon from forcing it to run in a way that undermines the above logic modern CPU's have.

Hope that makes sense and if I'm wrong, someone please correct me.

[Kresslack]

Origineel geplaatst door mansman:

Disclaimer: This processing approach is specific to applications that implement a main loop, such as simulation games. It is not intended for use in general multi-threaded applications such as a web server or deep packet inspector. It's actually designed in such a way to allow easier migration from the single thread game loop model commonly used to a multi-threaded model.

Basically you still have a primary game loop thread that is responsible for executing the same task sequencing it already does, it just doesn't end up doing all the actual task work as well. Each section of the game loop that iterates over similar objects, such as moving items on conveyor belts over one space, the task space is divided into discrete tasks. These tasks are then allocated to a number of pre-existing worker threads that were created based on available system cores.

The main loop thread also keeps a number of tasks to execute itself so it's not just waiting around for the other tasks to complete. When it completes its work, it checks to see if the remaining tasks are also complete or waits for their completion. Once all work associated with that section of the game loop is finished it moves on to the next section using the same map-reduce style of processing.

Since each task is discrete and no portion of the underlying information set is shared between tasks, they can be completed without locking. The only locking is the work threads contending with each other to pick up available tasks off the task queue placed there by the main loop thread. The main loop thread ensures that the entire task set is complete before continuing on to the next. This is how you avoid collision without locks.

The main benefit is that you don't have to completely redesign the entire game. You are doing the exact same thing you used to do on a single thread but allowing the work to proceed in parallel where possible. You typically only need to make minor changes to the information set (like dividing buffers into discrete elements) to be compatible with the approach.

Hmmm...Id have to see the timer numbers for both executed under the same conditions. In most cases, if a main thread is waiting for thread joins it's just as slow if even a single task is running slowly for whatever reason... but your main loop is waiting for them all to return before it continues. It itself executing its own work is nearly pointless at this point, as it could just be threaded out too, there is still a point the main thread is waiting for other threads to return before continuing.

So in most cases, it becomes multi-threading for the sake of multi-threading, and consequently makes bugfixing much harder.

This is a point I try put out a lot... its not that game developers are shirking some kind of responsibility to multithread to take advantage of newer hardware... its not as many tasks as people think can be usefully broken out to run in a thread.

[mansman]

Origineel geplaatst door Kresslack:

Hmmm...Id have to see the timer numbers for both executed under the same conditions. In most cases, if a main thread is waiting for thread joins it's just as slow if even a single task is running slowly for whatever reason... but your main loop is waiting for them all to return before it continues. It itself executing its own work is nearly pointless at this point, as it could just be threaded out too, there is still a point the main thread is waiting for other threads to return before continuing.

So in most cases, it becomes multi-threading for the sake of multi-threading, and consequently makes bugfixing much harder.

This is a point I try put out a lot... its not that game developers are shirking some kind of responsibility to multithread to take advantage of newer hardware... its not as many tasks as people think can be usefully broken out to run in a thread.

There's a couple of things I'd like to clarify. The style of multi-threading I'm proposing is Task->Delegation and not Thread->Join. You are correct that Thread->Join performs poorly in a lot of cases outside of long running computations. This is mostly due to thread creation and join operations being extremely expensive.

The task oriented approach eliminates this overhead by creating generic task running threads once and leverages a pool for task delegation. The join operation is not needed as the completion disposition is managed by the task and not the operating thread. It has very little overhead and is the most common form of parallelism in use today (at least in the areas I work in).

The reason the main loop thread is still involved in task execution is that it provides an opportunity to determine whether any given section of the game loop warrants delegation. If the number of items to process is above some threshold, tasks are created and delegated. If not, the main thread simply processes the items inline. The delegation and reconstitution sections bracket the main thread processing and are optional.

If the main thread has finished its processing and the delegated tasks are not yet complete, it can go ahead and begin generating the next set of tasks or performing maintenance activities on other portions of the information set. It doesn't have to sit around doing nothing.

On a side note, there are other benefits to mutlithreading than just purely execution time though they can be related. Spreading the work across multiple cores can significantly reduce the overall thermal load placed on the CPU package as a whole. This can have knock-on performance benefits as you can avoid incurring thermal throttling at the individual core level.

[Waxer]

Hello. iw been reading this thread (and others) due to me having a save of 1.5k hrs and the performance are really starting to tank at 25-30 fps.

PC specs.
5900 AMD cpu
32 3600mhz ram
RTX 3080

iw upped the "max objects" long ago to keep playing without crashes.
Done a few cleanups by editor to downsize the number of items in the game.

After reading here on that the game was only using one core. i wanted to see it for myself.
I used HWinfo to see core usage. and yes it shows core.0 as the one being used.

Then i looked into a tool to try and make the game run on more cores.
Installed Process Lasso, looked up some info on it.

Now Process Lasso is showing All 24 logical processors are in use.
i do a test, and start disabling processors available for satisfactory, the game start to tank even more and when only 4 cores are left for the game its down to 10fps from 30.

So maybe HWInfo is wrong and the game is in fact using more then one core. at least that is how it looks, by testing it.

If i disable SMT (halving processors) i get a higher core performance, but game performance goes down a little.

Next thing could be a multicore oc. to see if that adds something.

Anyways. that is what i have experienced with the game performance.

GL

[mansman]

Saying the game uses 1 core isn't quite accurate. The game does most of its processing on a single thread. The OS will try to schedule long running threads onto the same core if possible to take advantage of caches but it's not a hard rule. That thread can be executed on any one of the cores or be bounced around by things like Process Lasso.

That's not to say that the game doesn't leverage other threads to perform maintenance tasks or other calculations outside of the main thread. It certainly does. However, the main work to run the simulation and update the render state is single threaded.

Bouncing the process around to other cores can end up with a performance gain (even over the loss due to cache miss) if your processor cooling isn't great and the CPU begins to throttle that core due to excessive heat. Having it bounce around ensures that no single core within the CPU package gets too hot so you avoid being throttled.