NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in <199911192358.PAA24109@kiev.wall.org>
Did I say I expect Perl to do the right thing? :-)
--Larry Wall in <199911200217.SAA24898@kiev.wall.org>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
did you try 9 jobs? (Score:1)
In most cases of parallel testing (for e.g. 12-40 short-running test files), I've found 8 or 9 jobs to be the sweet spot on a 2-cpu machine (assuming adequate ram.) With 3 tasks, I would see e.g. a 30-40% wallclock savings, vs 50-60% with -j 9.
I suspect it has to do with keeping the parser busy, but could be some cool aspect about the (Linux) kernel (starting near-concurrent tasks which access the same .pm/.so files on disk?)
Note that your wallclock lower bound is $cpu_time/$num_cpu - which is ~795s/2 =
Re: (Score:1)
A sweet spot at nine jobs seems to point to I/O bound processes, which makes sense given how much time Perl-based tests spend printing, the granularity of a lot of these tests, and the design of Perl's TAP tools.
More info? (Score:1)
Where can we get more info about how T::H decides which tests are okay to run in parallel? All I can find is a line in the 'Changes' log saying "Implemented rule based parallel scheduler."