[concurrency-interest] Performance regression in newest (6/20/2013) jsr166 update

Doug Lea dl at cs.oswego.edu
Wed Jun 26 11:36:48 EDT 2013

On 06/26/13 11:13, Ron Pressler wrote:

>  > Most of this can be reinstated though, which on a quick check of a quick
> touch-up recovers performance on your test case. Stay tuned.
> Great. Thanks.
> Obviously, FJ is mostly intended for batch parallelization, but it's such a good
> scheduler that online, low latency software is relying on FJ for scheduling. It
> would be a shame to sacrifice the async mode for the sake of the default mode.
> If it has to be done, maybe we should have different class for the async case?

Nearly all the (sometimes substantial) performance differences are
due to at most a few dozen lines of code scattered among a few
thousand, so it would be nice not to have to split these off.

Most differences reflect mainly-heuristic
signalling and related policies. For bulk parallelism
and most other usages, you need predictive wakeups
to ramp up computations, while most async loads benefit
from a more reactive scheme. (Part of which got
anti-optimized away in current version but will be
re-incorporated hopefully soon.


More information about the Concurrency-interest mailing list