[concurrency-interest] question from new-user/instructor: "x.fork(); x.join()" vs. x.compute()

Dan Grossman djg at cs.washington.edu
Sun Mar 14 20:00:11 EDT 2010


Thanks for the instant reply, Doug -- very helpful.  See below...

Doug Lea wrote:
>> Why am I seeing "x.fork(); x.join()" causing a trivial program to take
>> about 40x longer than the same program written using x.compute()?
> Short version:
> (1) Because there is nothing that does this optimization for you,
> So you must hand-optimize this case.

Makes sense; I didn't expect this optimization to be done for me -- but I was 
surprised it mattered to much.  If I understand correctly, this optimization 
eliminates half the calls to fork, which I had trouble mapping to a 40x 
performance difference.

> (2) Because of big warm-up effects.
> Try putting your test in a loop and repeating.
> For me (using current internal snapshot on an Intel i7);
> with FORK true, I get on the first iteration:
>   parallel: 729 sequential: 38
> and the 20th
>   parallel: 26 sequential: 11
> With FORK false, first:
>   parallel: 177 sequential: 38
> 20th:
>   parallel: 7 sequential: 11
> 
> Which reflects that that after warmup, "fork(); join()" is around
> 4X-10X the overhead of just a straight method call. But it takes a while
> for a JIT to decide to compile the workstealing code, so the first
> runs are terrible. 

I also see dramatic improvements after the first run, both for FORK true and 
FORK false.  In steady-state, I have numbers like
with FORK true: parallel: 781 sequential: 31
with FORK false: parallel: 31 sequential: 31

There is jitter in the numbers, for example, the sequential is sometimes 47 or 
63, but ballpark the FORK-false gets about 1.5-2x faster after warmup and the 
FORK-true gets about 3-4x faster after warmup.  So the 40x difference drops to 
about a 20x-25x difference.  That still seems like a lot -- higher than the 
overhead of the fork and join calls and not due to warmup.

> Yes, this is a problem. We are working on it.
> You might have seen even more extreme results because current
> uncommitted version addresses some of this.

If a newer version is Java 1.6 friendly and stable for these simple sorts of 
programs, I'd be happy to try it out.  I won't be unleashing my students on 
JSR166 for about 8 weeks.  Their programs will do things a bit more 
interesting than my sample program (e.g., some 2D-arrays), but not in terms of 
the JSR166 features they'll be using.

--Dan


More information about the Concurrency-interest mailing list