One Core close to 100% while gaming

[kunack]

Guys, is this: http://imgur.com/Mu7kp normal to have only one core close to 100% while gaming? I have this weird stuttering issue while playing diablo 3 and I'm trying to get down to the culprit and whether it's cpu, gpu, or vsync related. If this is normal, I swear I'm not trolling.

 

[abekl]

Looks normal to me. It;s not unusual for even a multithreaded application to have a higher affinity for a single core.

 

[Viking2121]

It depends On the game really, If I run Arma II DayZ, 1 of my cores are at 80 - 90% usage on a x6 1100T 4ghz, while the other cores are working but not as much as that 1 core. Even other games I have sometimes do the samething, Call of Duty Black Ops does that, well in map loading 100% CPU usage on all six cores. It just depends on the game/program.

 

[InvalidError]

Guys, is this: http://imgur.com/Mu7kp normal to have only one core close to 100% while gaming?

It is normal to have most load dumped on a single core for any application that makes little use of multithreading or has poor thread concurrency, which is often the case with games.

In typical threaded games, you usually end up with the main thread that does most of the work, another that does some fair amount of work and a few helper threads that do a little bit of miscellaneous background work. If the OS or game sets thread affinities which makes execution slightly more efficient, you end up with uneven load distribution.

 

[rds1220]

It is normal to have most load dumped on a single core for any application that makes little use of multithreading or has poor thread concurrency, which is often the case with games.

YES EXACTLY!!

 

[Pearlmam]

It is also normal to see non-multithreaded applications to use one core-worth of your CPU (25% in your case) and spread between all the cores. The OS spreads the work for some reason. In fact, I see this behavior more than I see what is going on with your computer.

I assume that what is going on in your case is that it has something to do with what InvalidError said about the game itself setting up affinities.

 

[InvalidError]

It is also normal to see non-multithreaded applications to use one core-worth of your CPU (25% in your case) and spread between all the cores.

Which behavior you get depends on a few things: CPU drivers, power management settings, CPU-specific scheduler tweaks, application settings, context switch frequency, overall CPU load, etc.

Performance optimization wants to minimize context switches by leaving threads on the same core as much as possible. Power management wants to run everything on a single core as much as possible to avoid waking up other cores. On a system with aggressive power management, sub-100% single-core load and low enough interrupt rate that the OS does not need to wake up other cores to service interrupts, there are cases where all load lands on a single core.

With more performance-oriented profiles, threads that get yanked out of one core get re-scheduled to whichever core becomes available at the next opportunity and you get more evenly distributed load unless the user or application specifies otherwise.

 

[Pearlmam]

Which behavior you get depends on a few things: CPU drivers, power management settings, CPU-specific scheduler tweaks, application settings, context switch frequency, overall CPU load, etc.

Performance optimization wants to minimize context switches by leaving threads on the same core as much as possible. Power management wants to run everything on a single core as much as possible to avoid waking up other cores. On a system with aggressive power management, sub-100% single-core load and low enough interrupt rate that the OS does not need to wake up other cores to service interrupts, there are cases where all load lands on a single core.

With more performance-oriented profiles, threads that get yanked out of one core get re-scheduled to whichever core becomes available at the next opportunity and you get more evenly distributed load unless the user or application specifies otherwise.

That's interesting. to recap, to minimize power, the management would put everything on one core. The game would run on one core at sub 100%, and any interrupt that comes along would be handled by the one core.

To maximize performance, threads are divvied out to whichever core is available. Interrupting a particular thread to switch cores, however, would give a slight slowdown to the program. I don't understand why the OS would allow a particular thread to get "yanked" out as you put it. I guess if it has to handle an interrupt, the interrupt takes priority, leading to the overall performance of the computer maximized? This leads me to the question of:

Should you leave the OS to manage the cores or should the user intervene to maximize performance of a single program? For example: should the user set the affinity of a serial program (utilizes only one core) set the affinity to only one core? Maybe also set the priority higher? Or should you let the OS do what it does? This may not apply to Diablo 3 because it may have multi-threads.

 

[FinneousPJ]

You should let the OS do what it does 99,9% of the time. Microsoft has some brilliant minds and tons of money going in to develop this.

 

[gamerk316]

Yeah, as a general rule: You are not smarter then the windows scheduler.

 

[Pearlmam]

Yeah, as a general rule: You are not smarter then the windows scheduler.

nuh uh! I am too! Thanks for the answer. I think I have run some rough experiments (timing the execution with my watch) in the past with this and they confirmed what you said. Manually setting the affinity showed no gains and sometimes showed loss.

 

[InvalidError]

Manually setting the affinity showed no gains and sometimes showed loss.

Which is to be expected:

If the OS kicks your affined threads out of a given core to run something else, those threads will not be allowed to run on any other cores and therefore cannot run again until whatever is hogging the allowed cores is done. If you let the OS do whatever it wants, the threads will get re-scheduled to the next available core instead of waiting for its previous core to get freed up again.

Letting the OS schedule as it sees fit gives the threads more opportunities to run again sooner.