Loose-ends wrapup

[Brian Goetz]

Our new mantra is "explicit but unobtrusive parallelism."

As a low-level component, I think the xxx(minParSize...) is a perfectly 
reasonable API.  And xxx(minParSize...) could be argued to meets the 
mantra, but only just barely, because of the Concurrent in the class 
name.  If the bulk ops on CHM were cordoned off via some naming 
convention to make it clear which subset were possibly-parallel, that 
would help further.

On 5/19/2013 3:25 PM, Doug Lea wrote:
> 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
> hinting.
>
> -Doug
>
>
>>
>>
>> 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.
>>>
>>> Against:
>>>
>>> * 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.)
>>>
>>> -Doug
>>>
>>>
>>>
>>
>