Re^3: Is fork() my answer to using dual-cpu?

Actually, you probably want:

 $pm = Parallel::ForkManager->new(3);
[download]

unless your script has absolutely no disk I/O. Otherwise you will find that you have a processor sitting idle waiting on disk I/O. You might see an improvement with numbers greater than # CPUs + 1, but only in systems with highly parallelized I/O chains.

The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon

Comment on Re^3: Is fork() my answer to using dual-cpu? Download Code

Replies are listed 'Best First'.
Re^4: Is fork() my answer to using dual-cpu? by radiantmatrix (Parson) on Oct 26, 2005 at 18:58 UTC
Two things: first, the OP asked specifically about 2 processes; you are absolutely correct that more than 2 is probably better, but the exact number should be arrived at through careful profiling and testing. Second, it is an excellent point that multithreading may be premature optimization: if one's execution speed is bound by some resource other than processor time (e.g. I/O, RAM, network throughput, etc.), then one might actually slow things down by multithreading. Again, profiling and testing are important. Thank you for pointing these out, as I'd clearly forgotten to do so. <-radiant.matrix-> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code "In any sufficiently large group of people, most are idiots" - Kaa's Law	[reply]

Replies are listed 'Best First'.

Re^4: Is fork() my answer to using dual-cpu?
by radiantmatrix (Parson) on Oct 26, 2005 at 18:58 UTC

Two things: first, the OP asked specifically about 2 processes; you are absolutely correct that more than 2 is probably better, but the exact number should be arrived at through careful profiling and testing.

Second, it is an excellent point that multithreading may be premature optimization: if one's execution speed is bound by some resource other than processor time (e.g. I/O, RAM, network throughput, etc.), then one might actually slow things down by multithreading. Again, profiling and testing are important.

Thank you for pointing these out, as I'd clearly forgotten to do so.

<-radiant.matrix->
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

[reply]