Say I run a simple single-threaded process like the one below:
public class SirCountALot {
public static void main(String[] args) {
int count = 0;
while (true) {
count++;
}
}
}
(This is Java because that's what I'm familiar with, but I suspect it doesn't really matter)
I have an i7 processor (4 cores, or 8 counting hyperthreading), and I'm running Windows 7 64-bit so I fired up Sysinternals Process Explorer to look at the CPU usage, and as expected I see it is using around 20% of all available CPU.
But when I toggle the option to show 1 graph per CPU, I see that instead of 1 of the 4 "cores" being used, the CPU usage is spread all over the cores:
Instead what I would expect is 1 core maxed out, but this only happens when I set the affinity for the process to a single core.
Why is the workload split over the separate cores? Wouldn't splitting the workload over several cores mess with the caching or incur other performance penalties?
Is it for the simple reason of preventing overheating of one core? Or is there some deeper reason?
Edit: I'm aware that the operating system is responsible for the scheduling, but I want to know why it "bothers". Surely from a naive viewpoint, sticking a (mostly*) single-threaded process to 1 core is the simpler & more efficient way to go?
*I say mostly single-threaded because there's multiple theads here, but only 2 of them are doing anything:
The OS is responsible for scheduling. It is free to stop a thread and start it again on another CPU. It will do this even if there is nothing else the machine is doing.
The process is moved around the CPUs because the OS doesn't assume there is any reason to continue running the thread on the same CPU each time.
For this reason I have written a library for lock threads to a CPU so it won't move around and won't be interrupted by other threads. This reduces latency and improve throughput but does tire up a CPU for that thread. This works for Linux, perhaps you can adapt it for Windows. https://github.com/peter-lawrey/Java-Thread-Affinity/wiki/Getting-started
I would also expect this could well be done on purpose by the CPU and OS so as to try and spread the thermal load on the CPU die...
So it would rotate the (unique/single) thread from core to core.
And that could admittedly be an argument against trying to fight this too hard (especially as, in practice, you often will see better improvements by simply tuning / improving the app itself anyway)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With