ForkJoin wakeup update
gregg at wonderly.org
Thu Oct 18 11:38:24 PDT 2012
On 10/18/2012 1:03 PM, Doug Lea wrote:
> On 10/18/12 13:29, Aleksey Shipilev wrote:
>> Following Doug's advice, I've did a few experimental changes, described
>> * vanilla: plain vanilla FJP
>> * wakeup-3: wake up 3 threads instead of 2 during wakeups
>> * wakeup-4: wake up 4 threads instead of 2 during wakeups
>> * scan-busyloop: replace park in scan() with yield
>> On the same machine , the scores are:
>> vanilla: 429 +- 22 us/op
>> wakeup-3: 415 +- 15 us/op
>> wakeup-4: 390 +- 18 us/op
>> scan-busyloop: 150 +- 15 us/op
> Thanks! This leads to a much more precise version of
> my main observations about FJ in other contexts:
> * The break-even point (in terms of elements * cost per element)
> can be reduced by about a factor of three at the expense of wasting
> the world's power by keeping parallel worker threads spinning.
> Which we really do not want to do.
> * Short of that, the case for being only a bit more aggressive
> (and possibly wasteful) in initial startup wakeups isn't all that
> compelling but might be worth more tuning effort.
> * The main systems-level goal should be to find ways to make
> wakeups faster. Possibly entailing support of some sort of bulk
> signalling facilities?
Might there be some opportunity to use a PID mechanism here so that some amount
of dynamic tuning might happen automatically?
More information about the lambda-dev