Processing-Mode Equality
Sam Pullara
spullara at gmail.com
Sun Feb 9 12:17:39 PST 2014
I agree. And if we clearly lay out in the description of parallel streams that this is generally necessary, then people will know that they shouldn't just choose parallel() because their code can run correctly in parallel.
What I think we should offer is a nice SPI for implementing this behavior that gets runtime information about the progression of the pipeline execution so it can sample actual performance and change from sequential execution to parallel execution when conditions merit it. Deciding before starting the pipeline, even at runtime, is probably not that great since you will not often know the number of elements or the performance of the execution unit. I'm sure with something like that in place, there will be good implementations from at least Guava and Apache — and probably Oracle at some point.
Sam
On Feb 9, 2014, at 12:09 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 02/09/2014 02:15 PM, Sam Pullara wrote:
>> My point is that it is currently not decidable whether parallel execution will
>> be a win or a loss at compile time — but currently that is where we expose the
>> choice.
>
> I'm not sure what you mean. Anyone can write their own helper methods
> that return either parallel or sequential streams based on
> any (dynamic) information they choose. They are not built in, because
> any we could have offered would have been worse than not offering
> any at all. Perhaps a third-party industry will grow to fill this gap.
>
> -Doug
>
>
>
>
>
More information about the lambda-dev
mailing list