On Thu, Jan 5, 2012 at 2:37 AM, Dawid Weiss
<[email protected]> wrote:
>> With the Python runner I see these run times on just lucene core tests:
>>    2 cpus: 72.2 sec   5 cpus: 35.0 sec  10 cpus: 28.1 sec  15 cpus:
>> 26.2 sec  20 cpus: 26.0 sec  25 cpus: 27.5 sec
>
> I would say this is aligned with my intuition -- after you exceed the
> physical number of cores things don't speed up anymore.
>
>>   10 cpus: 88.3 sec  15 cpus: 80.2 sec  20 cpus: 77.4 sec  25 cpus: 76.7 sec
>> The above were just running on beast, but the Python runner can
>
> This is probably because some tests don't add anything to CPU load
> (they're disk bound or use the network)? The speedup is also not that
> significant -- adding 15 cpus only yielded about 10 secs.

Right... looks like most of the gains are by 10 CPUs.  Still I'll take
10 seconds ;)

>> Hmm so does that include compile time (my numbers don't)?  Sounds
>> likeno?  I'm also measuring from first launch to last finish.
>
> Oh, you mean ANT compile/ execution time before actual testing? No, I
> don't include that -- the execution time is actual spawned jvms.

OK good.

>> Yes I think that's the problem!
>> Ideally ant would just gather up all "jobs" to run and then
>> we'daggregate/distribute across JVMs.
>
> Could be done by emitting test class/ classpath names from each module
> and then running a final testing task that would execute whatever was
> appended to the current run... but it seems clumsy to me, don't know
> how to do it better though.

OK.... we lose a lot because of this.  Though, I haven't tried w/ your
git clone -- can it run a top-level "ant test" and it does the load
balancing by module...?

>> tochange the JVM settings (eg CLASSPATH) per test module we havetoday
>> so we must make separate modules for that...?
>
> Yeah, that would be one thing -- different classpaths/ vm properties
> etc. This could be problematic.

The Python runner completely cheats here, which is bad (because we may
pick up a dep we didn't intend to, and never catch it)... just takes
the union of all CLASSPATHS.

>> I re-ran above -- looks like the times came down some so the new
>> antrunner is basically the same as the Python runner (on core tests):
>> great!
>
> Thanks. I'm still working on the rough edges (like reporting a jvm
> crash, there were problems with ibm j9) and Stanislaw is preparing a
> nice(r) test report. We will contribute a patch once this is done and
> if there is interest we would love to contribute this in.

Awesome!

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to