22 Feb
2012
22 Feb
'12
5:22 a.m.
> [W]hile job X is waiting for the disk, job Y can
be doing something
> CPU-bound. [...]
Right, if certain tasks are cpu bound and other tasks
are i/o bound
then perhaps [...]
But if everything is I/O bound then I don't see
how parallelising it
would help.
It won't, in most cases. (It still may in a few special cases.)
But few-to-no of the things make is used to drive are really very close
to totally CPU-bound or totally I/O-bound. Compilations, for example,
are typically I/O-bound for a little while, then CPU-bound for a bit,
then I/O-bound again briefly. Depending on how the compiler is
designed, of course, the details will vary - for example, there may be
three phases of I/O and two of CPU - but the basic idea is still valid;
on a short time scale, it switches back and forth between I/O and CPU,
and the scheduler is entirely capable of giving the CPU to task Y while
the disk gets around to handling task X's I/O; even if it's only a
clock tick or two before things switch places, that's enough to help.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B