22 Feb
2012
22 Feb
'12
3:23 a.m.
On 21/02/12 9:56 PM, Mouse wrote:
Right, if certain tasks are cpu bound and other tasks are i/o bound then
perhaps we run into the more subtle analysis hinted at by Sean, where
accidental overlaps might be helping (since nothing is done to
*deliberately* optimise this situation).
But if everything is I/O bound then I don't see how parallelising it
would help.
--Toby
> It's
superlinear because [...]
- assume a very small cache in relation to
source
- parallel job kicks off 1..N compiles, let's say N unique source
files and 20*N common include files. So each compile process works
through 21 files.
- the problem is, if your cache is smaller than that overall job,
ANY of these compiles is going to blow the cache. Running in
parallel doesn't help.
Doesn't help with the cache, but does help, because while job X is
waiting for the disk, job Y can be doing something CPU-bound.
Single-job it, and all your wait-for-disk moments will be spent idling
(at least as far as getting the make done goes).
/~\ 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