Processing-Mode Equality
Doug Lea
dl at cs.oswego.edu
Sun Feb 9 04:42:51 PST 2014
One slogan is "Data-centric, parallel-agnostic".
On 02/08/2014 01:36 PM, Sam Pullara wrote:
> 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.
This of course assumes that people will continue to write programs in
ways that present a high likelihood of disappointment. This is sure to
sometimes happen: Classic object-oriented programmers will tend to use
unpartitionable side-effecting methods, classic functional programmers
will tend to use hopelessly sequential data structures, and classic
event-driven programmers will tend to use one-by-one vs bulk updates.
Among those likely to cope best are database programmers, who are
already comfortable with data-centric bulk updates.
> A pretty special set of conditions need to
> be present for it to make sense to run things in parallel.
In some alternative universe, someone is now complaining that a
pretty special set of conditions need to be present for it to make
sense to run things sequentially even if eligible for parallelism:
The combination of intrinsically sequential data structures,
less than a few thousand elements, and trivially cheap per-element
functions. If you designed programs so these cases rarely occurred,
you wouldn't worry about occasional slowdowns when they do.
But we cannot write such code for you. We cannot even tell you
with certainty when you do/don't: Just trying to figure out the
cost of per-element functions hits the Halting problem.
We will see some bad reactions and experiences along the way
as people decide how and when to use the Stream framework.
And we will surely see people deciding to never use it because
data-centric, parallel-agnostic programming clashes with their
adopted programming style. Fine. Java (among other JVM languages)
succeed because people with different religious views about
programming can coexist.
-Doug
More information about the lambda-dev
mailing list