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

Ron Pressler ron.pressler at gmail.com
Wed Jun 26 12:07:37 EDT 2013

On Wed, Jun 26, 2013 at 6:36 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 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.
A couple of months ago (regarding the benchmark), you said this:

> The underlying issue is that the pushing task does not know that
> the single worker is already available, so activates another.
> (It can take a few dozen nanoseconds for workers to rescan before
> idling.) So it is not so much parallelism-level as intrinsic raciness.

So is the intention to improve this in the default mode only, or
will you address the problem in the async mode, too?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130626/bad1ce5b/attachment.html>

More information about the Concurrency-interest mailing list