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

Doug Lea dl at cs.oswego.edu
Thu Jun 27 10:37:44 EDT 2013

On 06/26/13 12:07, Ron Pressler wrote:
> On Wed, Jun 26, 2013 at 6:36 PM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
>     Most differences reflect mainly-heuristic
>     signalling and related policies. ...
> 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 is the intention to improve this in the default mode only, or
> will you address the problem in the async mode, too?

Stepping back a bit: Work-stealing has many, many advantages
over other schemes, but also has one source of overhead that
can hurt in some usage patterns: In order for a thread to
steal work, it must be awake (not blocked). (Aside: in
classic high-performance applications, this doesn't arise
because you can just keep them all awake spinning for the
duration of a program. People would not appreciate it
if we did this in Java.). Once computations get going
and there is no one left to wake up, this overhead evaporates.
But otherwise, blocking and unblocking threads on modern systems
is just not cheap (and further compounded by bookkeeping required
to check if wakeups are or may be needed). For example, in your
FJBenchmark program, I measure that this accounts for about 77%
of the run time. So, performance on artificial benchmarks like
this is heavily impacted by small details in how we manage to
avoid some or all of this overhead across various cases. The last
update hurt a bit on this benchmark, but even still, I'm not
sure yet whether it hurt more than helped any actual async usages.
As I said, stay tuned...


More information about the Concurrency-interest mailing list