8 cores processor load not well balanced

[sinarca]

I have this processor:
Intel Core i7-950: 3066.7 MHz.
I notice that the load of the eight cores is not equally distributed.

Is there a way to fix it ?
Thanks

 

[morsify]

You could give this a try:

GSC runs mainly on one core only. But if you add the command +fullproc to the end of your target command line in the shortcut properties, it will tell it to use the whole processor (I don't know if it will use 8, but it certainly allows it to use 4 cores).

Right click on your GSC shortcut and in the target line it should look similar to this:

"D:\GSC2013\GSC.exe" +fullproc

 

[sinarca]

You could give this a try:

GSC runs mainly on one core only. But if you add the command +fullproc to the end of your target command line in the shortcut properties, it will tell it to use the whole processor (I don't know if it will use 8, but it certainly allows it to use 4 cores).

Right click on your GSC shortcut and in the target line it should look similar to this:

"D:\GSC2013\GSC.exe" +fullproc

Yes, I have set my shortcut setup but while I'm monitoring with MSI Afterburner (in OSD mode), I can see that the game is using all the 8 cores, but not all loaded in equal manner.
For example the n. one 10%, the n. two 5%, the n. three 70% and so on.
Why not 12,5% for all the 8 cores ? (12,5x8=100%)

 

[dbigers]

Warning, long post ahead.

The question you are asking is one that developers have been trying to solve for at least the last decade or so. Some tasks can be easily run in parallel, which allows equal loading of all available cores.

The classic example is 3D rendering and raytracing. In those apps, every extra core, or in some cases, each extra processor, can add dramatically to the speed of completing the task. Often, 3D modeling and rendering programs will divide the frame into chunks or tiles. Each core in the processor is assigned a tile. When it finishes a tile, it requests another. This repeats until that frame has rendered entirely. Then the next frame is started. This is repeated over and over. Other apps that run well in parallel are video encoding and also many scientific applications.

Developers are searching for ways to code other, more common everyday apps to more efficiently utilize extra cores as easily as it happens in those examples. Games and most other apps have completely different workflows than rendering. They just don't lend themselves to running in parallel as easily. Another thing is that a lot of this is "new" to developers. When I say new, I mean like in the last decade or so. For the longest time, developers had only one processor/core to worry about.

If you recall, for the longest time, everything was a mhz race. Each year, faster and faster. Years back though, it was realized that we couldn't just keep ramping up cpu speed. Enter multi-core processing. Actually, for tasks like 3D rendering, multi-processor systems were around long before the idea of multi-core processing. Instead of multiple cores in a processor, those systems used two or more processors on one motherboard.

Back to programming though and ways to tackle the problem. One thing developers are doing recently is offloading different kinds of tasks to different threads. Sort of a divide and conquer. For instance, physics, sound, etc. Each kind of task can spawn its own thread, utilizing its own core. That is a start at more efficient use of extra cores. Although not as efficient as a truly parallel task, it is a start.

Because these are separate and independent tasks though, each one may require resources differently from the other. For instance if the physics calculations finish for the current frame, player input might be used to begin the next calculation. Sound on the other hand, likely doesn't need updating as regularly, therefore requiring less resources. That is one of the reasons you don't see equal loading of all cores. If you have ever used a 3D rendering program or video encoder though, you will see equal loading amongst all cores most all of the time.

Multi-core and multi-processor programming is a paradigm shift. It is going to take some very creative programming techniques to make everyday tasks more parallel friendly. Along with new programing techniques, new compilers will be necessary as well. Until then, divide and conquer will be the order of the day.

Tasks that can easily be run in parallel, already do and did so almost immediately upon the arrival of multi-core systems. In fact, those types of tasks were one of the driving factors for the creation of multi-processor and later multi-core.

 

[sinarca]

Many thanks dbigers for the ultra professional explanation !!