At what point will two CPU processes interfere with each other?

5

1

I'm running multiple processes on my CPU simultaneously, and now I am trying to find out how much CPU power each of them can use until they start disturbing each other:

For simplicity's sake let's assume a machine with a single CPU, and assume CPU is the only resource that is relevant.

We now have two different processes running on our single CPU on a Windows 7 64-bit machine at equal CPU priority. We'll call them P1 and P2. Both P1 and P2 use 20% of the CPU each.

  1. Will they both run the same way as they would if the respective other wasn't running aswell?
    Logically they would since there is more than enough CPU power for both of them to run. However due to sharing of the CPU the actual situation may be different.

  2. If the answer to 1. is yes: At what point will they begin interfering with each other?
    Will they only begin interfering with each other once both of them try to use more than 50% of the total CPU power, or will they interfere much earlier for whatever reason?

  3. Would the answers to the previous questions be different if it was more than 2 processes, or different kinds of processes (with multiple threads each for example), and how would they be different?

Wingblade

Posted 2014-10-05T01:06:03.613

Reputation: 162

Answers

7

Ignoring overhead from the other processes (you tagged Windows 7). The kernel will queue each thread in the order that they are ready. There's a lot more in there but that's the general gist.

Each program will do many things, like make reads or writes to the disk or memory, each of these is it's own task. If each process will ever only use 20% of the CPU; P1 will get to run one task, then P2 will run one. If P2 becomes ready first in the second round P2 will run one followed by P1. This will continue until each completes and exits.

Now process utilization of 100% means that every measured time, (in this example 1 second,) so every second the processor is ALWAYS busy, and it always computing. In your example of 40% usage every second the processor is working, making calculations, for 400 milliseconds. So after 10 seconds the processor has been in standby for 6 seconds total. (Ignoring other programs, and over head)

  1. Effectively yes. If you hand only one running at a time, the overhead of switching back and forth wouldn't apply, but if the processor is only at 40% it's not really an issue.

  2. If each program needed 100% of the processor then you'd notice some lag time for the switching back and forth. Remember, a single core can really only do one thing at a time, it seems like it does more because it's really fast at switching back and forth. Each at 50% plus about .01% of overhead means 100.01% so you'd be "waiting" for 10 milliseconds.

  3. Yes, in the intro each program had a number of tasks, with multiple threads each task the program had to do (read, and then write) would get into the queue sooner, so the "waiting" time would be less and you'd be able to pack the 40% CPU usage into the first 400 milliseconds, instead of having to include wait time forcing the work to be spread out into something like 600 milliseconds. It's effectively the same with more programs, there's more overhead for each, but it's still negligible. (Unless you get into real time systems.)

Again this is super general, but it's more or less how multiple programs share a single CPU. The issues arise when the logic/program/scheduler is bad at ordering the task queue, this causes more overhead, the more overhead the more waiting time, so even if your program needs only 40% each, the overhead of switching will cause 30% more time switching tasks or waiting around.

Gregory Mullen

Posted 2014-10-05T01:06:03.613

Reputation: 86

Really good answer +1. So the only possible issue would be waiting times resulting from one process being ready earlier? Are these waiting times noticeable? And is there a way to reduce the waiting times of one process at the cost of the other process's waiting times? Like with changing priority or something? – Wingblade – 2014-10-05T01:48:57.973

1There's effectively no change by what program is ready first. Wait times are nearly insignificant in a windows environment; they don't become a problem unless you're hardware is severely underpowered.

Changing a priority only changes how the queue gets sorted, the queue sorted (called a scheduler) the thread scheduler will attempt complete all tasks from the higher priority program first, and a good one will not forget about the lower priority programs, and give them a fair share of the CPU. – Gregory Mullen – 2014-10-05T01:51:23.737

So I have nothing to worry about then? Would giving one of my processes higher priority still help it in some way (say if there is a sudden spike in CPU usage)? – Wingblade – 2014-10-05T01:54:42.123

1No, with the exception of the realtime priority you can't really hurt other programs execution, if you're constantly near 100% you might get screwed, but not in day to day usage. But still be careful with what you change. E.g. changing Chrome to a higher priority won't make it faster, it will only make everyone else have to wait just a little longer. The only times you will ever notice a change being helpful is lowering something that's hard on CPU cycles like transcoding A/V, or rendering, that way your computer works normally and it gets what's left. (PS I edited my first comment.) – Gregory Mullen – 2014-10-05T02:04:46.980

That pretty much covers all my concerns, answer accepted. One of my processes is in fact A/V encoding-related, so I will put that to lower priority. – Wingblade – 2014-10-05T02:08:42.097