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

Ramesh Mandaleeka ramesh.mandaleeka at gmail.com
Sun Mar 14 21:22:57 EDT 2010

I had the same situation, but I hesitated a bit to ask. :)


On Sun, Mar 14, 2010 at 8:00 PM, Dan Grossman <djg at cs.washington.edu> wrote:

> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100314/140f35d2/attachment.html>

More information about the Concurrency-interest mailing list