ForkJoin wakeup update

[Dave Dice]

On 2012-10-18, at 3:26 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 10/18/2012 10:03 PM, Doug Lea wrote:
>> 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.
> 
> Yeah, it also gives the upper limit on what we can do in parallel.
> Comparing this against sequential version, sequential case is doing the
> same thing in 450us (since we are at break-even point), which actually
> means we throw 24x more threads in, but get only 3x improvement, so then
> the rough estimate for sequential work we do is 30%. Gotta churn out
> that as well.
> 
>> * 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.
> 
> It might very well turn out the quicker rampup does compelling
> improvements on larger machines, 24 hardware threads is nothing these
> days. Will look around for 4x10x2 and greater machines.
> 
>> * The main systems-level goal should be to find ways to make
>> wakeups faster. Possibly entailing support of some sort of bulk
>> signalling facilities?
> 
> Yes, the ball is in Dave's court here.

I'd still like to see the results of a hard spin with no yield().   Yield is often a disaster on solaris and linux.    

Regards
Dave

> 
> -Aleksey.
> 
>