This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: parallelize objc testing a bit more


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]