ForkJoin wakeup update

Gregg Wonderly 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
>> below:
>>    * 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 [4], 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?

Gregg


More information about the lambda-dev mailing list