dl at cs.oswego.edu
Sun May 19 12:25:40 PDT 2013
On 05/15/13 11:14, Brian Goetz wrote:
> Even if we accept that hinting is needed, its not clear what the best hints are;
> hints about Q might be more useful than attempting to set splitting parameters.
> (And, there are more than one splitting parameter we might want to set. For
> example, if the pipeline has a highly selective filter, we might want to adjust
> target chunk size.) And hints beget more hints.
> So I still don't think we know what we'd want even if we knew we wanted
> something :(
What about the follow-up question. Suppose we did this
in CHM only. That is, instead of xxxSequentially(fn, ...) vs
xxxInParallel(fn, ...), there were only xxx(minParSize, fn, ,,,)
Because there's no stream pipeline, there's no cascade of
> On 5/15/2013 11:02 AM, Doug Lea wrote:
>> One more, that Brian and I have discussed off an on for a year or so,
>> that always ends up as too hard to decide.
>> Do we want to overload Collection.parallelStream(int minParSize)?
>> minParSize is the minimum number of elements to process in parallel,
>> else sequential.
>> And/or overload Stream.parallel().
>> Arguments for:
>> * Parallel performance for the combination of small N and
>> cheap lambdas (like adding numbers) is crummy. There's
>> little hope of automating decisions unless/until we can
>> automate cost metrics of lambdas, which is not going to happen
>> any time soon.
>> * People might want to write code that uses parallelStrerams
>> only if they have a lot of elements, that they might not
>> know ahead of time.
>> * Most people do not know what values are reasonable.
>> * The "best" values are likely to change in the future.
>> One compromise is to do this only for the custom CHM parallel
>> task methods, that are most likely to be used only by people
>> who are also most likely to want to tune performance.
>> (I'm on my way out to a conference program committee meeting
>> for two days, so replies might be slow.)
More information about the lambda-libs-spec-observers