stream() / parallelStream() methods
forax at univ-mlv.fr
Sat Feb 9 07:42:04 PST 2013
On 02/09/2013 04:36 PM, Kevin Bourrillion wrote:
> On Sat, Feb 9, 2013 at 4:09 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
> On 02/08/13 18:35, Kevin Bourrillion wrote:
> Doug, I am extraordinarily unmoved by this concern. :-) Does
> a break-even point
> moving a few elements in either direction really matter?
> People dealing with parallel library support need some attitude
> adjustment about such things. On a soon-to-be-typical machine,
> every cycle you waste setting up parallelism costs you say 64 cycles.
> You would probably have had a different reaction if it required 64
> object creations to start a parallel computation.
> Well, that would also have 64x the effect on young gen GC.
> I still wouldn't immediately blanch at the 64 allocations. Do users
> really want to use parallelism to get savings /that/ small? I thought
> we would care more about the cases in which the parallelism is a huge
> win, not so marginal.
It depends if the operation that you perform for each item take a long
time or not.
> That said, I'm always completely supportive of forcing implementors
> to work harder for the sake of better APIs, so long as the
> APIs do not rule out efficient implementation. So if killing
> parallelStream is really important, we'll find some way to
> turn stream().parallel() into a bit-flip or somesuch.
> I will stop short of trying to convince us it's "important", but I
> would definitely agree that if the cost is only some implementation
> ugliness, that shouldn't be enough to justify the method existing.
More information about the lambda-libs-spec-observers