Processing-Mode Equality

[Brian Goetz]

If your point is that making it easy to say ".parallel()" doesn't make 
parallelism easy, well, duh.

In Java 7, it was really hard to rewrite your algorithm to be parallel 
using fork-join, so only experts did it, and only when it was absolutely 
needed.  In Java 8, you're encouraged to solve the problem in a 
parallelism-agnostic way, and then you can easily switch back and forth. 
  But, you still have to understand and measure.  No magic bullet.


On 2/9/2014 5:24 PM, Sam Pullara wrote:
> Since parallel execution using this framework is fundamentally more expensive than sequential (CPU, memory and synchronization overhead) they are not the same. If developers use this framework and ignore that overhead they will see huge slowdowns on one side and OOMEs on the other. It might be beautiful to think of them as the same thing, but until we make sequential the common degenerate case of parallel based on metrics, I don't think people should think of it that way.
>
> Sam
>
> On Feb 9, 2014, at 2:07 PM, Richard Warburton <richard.warburton at gmail.com> wrote:
>
>> Hi,
>>
>> Here are just a few of the things you need to know at runtime to decide if you want to run something in parallel:
>>
>> They all also just a few of the things you need to know at runtime to decide if you want to run something sequentially. To my mind this is part of the point that Maurice was originally getting at: sequential isn't the default. There is no default.
>>
>> regards,
>>
>>    Richard Warburton
>>
>>    http://insightfullogic.com
>>    @RichardWarburto
>
>