Processing-Mode Equality

[Sam Pullara]

That is one way to think about it and programming wise you would be correct. However, if you run everything in parallel that can be you will likely be disappointed in the performance. A pretty special set of conditions need to be present for it to make sense to run things in parallel. Sadly the API forces the developer to decide at compile time when they can't possibly know if those conditions are present. Personally I think that parallel() should be nothing more than a declaration that the developer believes something may be parallelizable and make no claims as to what will happen at runtime and then we should make a concerted effort to make the right choice hotspot style.  My fear is that either they will rarely be used like Scala parallel collections or used all the time when they shouldn't be. Both outcomes will make the choice of including them dubious.   Sam    

---Sent from Boxer | http://getboxer.com

On Sat, Feb 8, 2014 at 3:56 AM, Graham Allan <grundlefleck at gmail.com> wrote:

> Hi Maurice,

>

> Seems like Brian's explanation is slightly mismatched with what you

> originally had in mind.



My impression is that the Stream interface is parallel only. It does

allow user to specify parallelism level = 1, a.k.a. the sequential

mode. The main reason for the sequential mode is that a lot of Java

programmers are imperative-minded, and they'll want to pass in

functions with side effects.



Zhong Yu



> Given that, how about: "Principle of Optimistic

> Parallelism"*. That the API was designed with the expectation and hope (but

> not decree) that the user takes advantage of parallel processing. Not sure

> it quite covers functional equivalency though.

>

> HTH,

> Graham

>

> * or "Parallelism Optimism" if you're in a rhyming mood.

> On 6 Feb 2014 15:56, "Brian Goetz" <brian.goetz at oracle.com> wrote:

>

> I like to look at this as having chosen a design center that recognizes

> that sequential is a degenerate case of parallel, rather than treating

> parallel as the "weird bonus mode".  I realize that this choice was

> controversial and definitely caused some compromises, but eventually

> people will have to start to unlearn their sequential biases, and

> there's no time like the present.

>

>  From the perspective of a hundred years from now, there is an optimum

> time in history to invert the primacy between sequential and parallel in

> programming-model design.  (For example, 1995 would definitely have been

> too early.)  That people are made uncomfortable by this subtle shift in

> priority might indicate that 2014 is also too early, or might simply

> reflect the fact that that people are always uncomfortable about change

> and whenever we did it we'd suffer the friction of people clinging to

> their increasingly unhelpful sequential assumptions.

>

> In any case, my perspective is not so much that there are two modes and

> that they should yield equivalent -- though not always identical --

> results (though this is true), but that one mode is a degenerate special

> case of the other, and we have chosen to focus (most of) our design

> effort on the general case, rather than catering to the special case.

> (We made a few exceptions, and overall, we may well have made too many

> exceptions rather than too few.)

>

> I realize people may disagree with our approach.  People are very quick

> to point out what they perceive as losses -- say, the lack of a

> takeWhile or other fundamentally sequential operation, and bemoan "why

> couldn't you just have made it a sequential-only operation?".  But what

> they usually don't see (or at least never say out loud) is that taking

> the general approach pays a simplicity dividend -- that we don't need to

> reason about special cases like "this operation is sequential-only."

> Irregularities breed complexity.

>

>

>

> On 2/6/2014 7:18 AM, Maurice Naftalin wrote:

>> In writing about streams, I want to explain how the API has been

>> shaped by the design goal of maintaining functional equivalence

>> between parallel and sequential execution. I'm looking for a name for

>> that goal, but so far the best I've come up with is the Principle of

>> Processing-Mode Equality, which is pretty clumsy. I'd appreciate

>> suggestions for improving it (which I will be happy to attribute).

>> Thanks in advance!

>>

>> Maurice

>>

>