parallelize objc testing a bit more

* Make-lang.in (check_objc_parallelize): Refine for 4 processor machines.
2011-02-21  Mike Stump  <mikestump@comcast.net>

	* Make-lang.in (check_objc_parallelize): Refine for 4 processor machines.

On Tue, Feb 22, 2011 at 12:20:26AM -0800, Mike Stump wrote:
> 	* Make-lang.in (check_objc_parallelize): Refine for 4 processor machines.

This doesn't seem to be a good idea to me.
At least in my testing
1) objc testing never even shows up on the radar
2) execute.exp takes roughly the same time as the rest of objc testing, both
   take about 3 minutes (when doing make -j48 -k check):
grep exp.*seconds objc*/objc*.log.sep
objc1/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc/execute/execute.exp completed in 177 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc/compile/compile.exp completed in 7 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc/execute/exceptions/exceptions.exp completed in 22 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/attributes/attributes.exp completed in 2 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/dg.exp completed in 37 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp completed in 24 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/lto/lto.exp completed in 2 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/pch/pch.exp completed in 3 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/property/property.exp completed in 15 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/special/special.exp completed in 2 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/strings/strings.exp completed in 1 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/tls/tls.exp completed in 1 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/torture/dg-torture.exp completed in 9 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/torture/strings/strings.exp completed in 32 seconds
objc/objc.log.sep:testcase /usr/src/gcc/gcc/testsuite/objc.dg/torture/tls/tls.exp completed in 13 seconds

So, by splitting off a 24 second job and a 22 second job separately, you just slow the whole regtest
down by increasing make overhead and time to merge the results back.  I doubt it can help
even with separate make check-objc -jN testing (and that is not the common case of people doing testing,
most people just do make -jN -k check in the toplevel and that is what we should optimize for).

We need to retune the parallelization, but the primary spot would be to split libstdc++ testing
some more (two more jobs?) and perhaps some of the larger check-gcc jobs too.

> 2011-02-21  Mike Stump  <mikestump@comcast.net>
> 
> 	* Make-lang.in (check_objc_parallelize): Refine for 4 processor machines.
> 
> Index: Make-lang.in
> ===================================================================
> --- Make-lang.in	(revision 170390)
> +++ Make-lang.in	(working copy)
> @@ -128,9 +128,8 @@
>  
>  # The following allows you to do 'make check-objc -j2'.  The
>  # execute.exp tests will be run in parallel with all the other ones.
> -# This is tuned for '-j2'.
>  lang_checks_parallelized += check-objc
> -check_objc_parallelize = execute.exp
> +check_objc_parallelize = gnu-encoding.exp execute.exp exceptions.exp
>  
>  #
>  # Install hooks:


	Jakub

On Feb 22, 2011, at 12:36 AM, Jakub Jelinek wrote:
> On Tue, Feb 22, 2011 at 12:20:26AM -0800, Mike Stump wrote:
>> 	* Make-lang.in (check_objc_parallelize): Refine for 4 processor machines.
> 
> This doesn't seem to be a good idea to me.

Well, on a standard linux box, I get:

before:

real	1m4.538s
user	2m33.710s
sys	0m42.230s

after:

real	1m2.078s
user	2m30.900s
sys	0m41.750s

so, this improved wall time, improved user time and improved system time...  Yes, the results are repeatable.

So, on linux, I'd call it a wash, or ever so slightly better.  But that isn't isn't quite why I did it.  On darwin, a ton more testcases fire, and splitting them up allows substantially faster testing:

gnu-encoding.exp completed in 259 seconds
execute.exp completed in 151 seconds
exceptions.exp completed in 120 seconds
dg.exp completed in 43 seconds
strings.exp completed in 19 seconds
...

I'd be curious in exactly how much slower it is for you?  I'm hoping that it is under 2 seconds.

On Tue, Feb 22, 2011 at 01:19:20AM -0800, Mike Stump wrote:
> Well, on a standard linux box, I get:
> 
> before:
> 
> real	1m4.538s
> user	2m33.710s
> sys	0m42.230s
> 
> after:
> 
> real	1m2.078s
> user	2m30.900s
> sys	0m41.750s
> 
> so, this improved wall time, improved user time and improved system time...  Yes, the results are repeatable.

Well, you are just testing check-objc, I don't think most of the people do
it, they just test everything (the exception are probably 3 people or so).

I'm worried just that there will be unnecessarily too many parallel jobs
where each one has its own extra fixed cost (merging logs takes some time
and some time spent in make).  That's why say C testing isn't split into
hundreds of parallel jobs (e.g. each *.exp given at least one job).

I didn't know that on Darwin it is so much more expensive, maybe the
tuning for ObjC if the testsuite is so wastly different there should
depend on whether it is darwin or not.

> So, on linux, I'd call it a wash, or ever so slightly better.  But that isn't isn't quite why I did it.  On darwin, a ton more testcases fire, and splitting them up allows substantially faster testing:
> 
> gnu-encoding.exp completed in 259 seconds
> execute.exp completed in 151 seconds
> exceptions.exp completed in 120 seconds
> dg.exp completed in 43 seconds
> strings.exp completed in 19 seconds
> ...

	Jakub