cpu time in parallel tests
Nicholas Clark
nick at ccl4.org
Sun Aug 31 18:10:02 UTC 2008
On Sat, Aug 30, 2008 at 05:00:07PM -0700, Eric Wilhelm wrote:
> # from Nicholas Clark
> # on Saturday 30 August 2008 15:12:
>
> >parallel, TEST_JOBS=3:
> > 222s (33.37 usr 11.58 sys + 251.99 cusr 49.48 csys = 346.42 CPU)
> >
> >serial:
> > 545s (31.38 usr 9.62 sys + 273.33 cusr 51.77 csys = 366.10 CPU)
> >
> >Um, so I'm actually using less CPU running the tests in parallel?
> >If so, that seems rather good.
>
> A 60% savings isn't unusual from what I've seen on most test suites
> (from say, 30 seconds upwards in serial spread across ~10 or more
> files.)
It certainly helps that three or four of the core test have quite a few
sleep()s in them, which in serial are just delays, but in parallel are
almost irrelevant.
> It is interesting that the cpu usage dropped by about 5% (346/366 =
> 0.945). Does this mean that sleep()ing is easier when you can get a
> lot of it done in parallel, or is perl (and possibly some modules?)
> managing to stay on the CPU cache?
I suspect that those numbers are wrong. They're from my MacBook, and after
trying to repeat runs this morning, and getting 5% differences in CPU time
I now suspect that it's throttling back the CPU when it gets too hot.
(Which is really irritating from a consistency perspective - start the tests
when it's cold - 222s. Start the tests just after the fans have calmed down -
232s. Leave it to get cold again - 222s)
Here are numbers from a 2 twin core rackmount Debian box. TEST_JOBS=5:
Files=1552, Tests=209707, 215 wallclock secs (66.60 usr 13.43 sys + 504.27 cusr 51.69 csys = 635.99 CPU)
Result: FAIL
real 3m36.677s
user 9m32.048s
sys 1m5.240s
and in serial
Files=1552, Tests=209707, 685 wallclock secs (38.91 usr 8.61 sys + 372.84 cusr 40.13 csys = 460.49 CPU)
Result: FAIL
Failed 3/1552 test programs. 3/209707 subtests failed.
real 11m26.022s
user 6m52.062s
sys 0m48.779s
So lots more CPU in parallel, including in the child processes. But still lots
less wallclock. Dear Sun, could we borrow that t2000 again?
Nicholas Clark
More information about the tapx-dev
mailing list