# [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
```