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