
A Java 8 Parallel Calamity - ssijak
http://coopsoft.com/ar/Calamity2Article.html
======
rewqfdsa
Does anyone else think like this article is written in a bombastic,
obfuscatory style? I feel like the author is more concerned about
communicating how very intelligent he is than warning other developers about
the dangers of fork-join frameworks. Who is he trying to impress?

~~~
rewqfdsa
Between on the author's explicit trademark annotations, division of the world
into "junior", "senior", and "architect", pretentious grammatical
hypercorrection[1], and casual dismissal of sun.misc.Unsafe use, I think I'd
hate working with the him.

[1] Why the fuck am I supposed to trust someone who doesn't understand the
distinction between "it's" and "its" to tell me that all of Oracle's language
designers got a core piece of infrastructure irrecoverably wrong?

------
webaholic
You know what would put the authors point across really well? Data. I wish the
author had written some benchmarks to show the performance degradation.

~~~
ignoramous
I emailed the author (Edward H), hopefully he has enough time to reply to some
of the points raised here on HN.

------
haddr
Java's parallel stream is a cool feature, but it's suitable only for small
batches of data.

Once i tried streams with lambdas to process a large corpus of data
(processing many items in a multi-stage manner). While the code was clean and
nice, the performance was horrible. A lot of thread waits, etc. Much worse
than handling the whole process on my own with thread pools.

Also there are many catches: for instance, when you start your stream with 1
item there will be only max 1 parallel thread to handle the data, and it
doesn't matter if you do some fancy data split on some stage of the stream.

~~~
LoSboccacc
Same experiences here. Had to process large number of texts to extract chains,
said why not and used java streams.

Total failure, could not even get one core feed consistently because they
where all fighting for resources.

Maybe could work for Non local or in memory data, but I rebuilt it with queues
and a thread pool and it was easy way faster.

~~~
PaulHoule
In terms of performance you really need to minimize contention. If you build
something that sends things round-robin to different spliterators you are
going to have horrible performance, you really need to batch 10,000 or so
lines and send those to different spliterators.

Also for anything that is pipelined there is ultimately going to be a
bottleneck at the weakest point, which could be the spliterator factory.

------
ysleepy
He does work for a company selling a competing product.

~~~
eccles
... and appears to own said company

~~~
tsotha
Ah. Now all is clear.

------
cooper6
First and foremost: I’m a programmer, not a web site developer or professional
author. If you don’t like my web site or writing style, too bad. The explicit
trademark specification came from legal advice. If you want to criticize
something I do well, then criticize my software. I maintain tree active open-
source products on SourceForge:

Task Parallel
[http://sourceforge.net/projects/tymeacse](http://sourceforge.net/projects/tymeacse)
Data Parallel
[http://sourceforge.net/projects/tymeacdse](http://sourceforge.net/projects/tymeacdse)
Task Parallel
[http://sourceforge.net/projects/tymeacand](http://sourceforge.net/projects/tymeacand)

The grist of the three articles is 1\. This framework doesn’t belong in core
Java. 2\. This framework should not be the parallel engine that drives all
parallel computing (streams etc.) in Java. 3\. It is still failing as a
parallel engine no matter what the engineers do.

A little history may help. In 2010, I submitted a proof-of-concept to the good
professor showing that scatter-gather works just as well as what he was
proposing for Java7. Since he ignored the proof completely, I took the
parallel engine out of a Task Parallel product I maintain and put in the Data
Parallel engine. This product is also open-source. It is not suitable for an
API since it is a full feature Data Parallel product. It is not for sale. It
is, and has always been, open-source. Data Parallel only works well on copious
processors, which is why I never bothered offering it before.

The software examples I submitted with the articles (downloadable) are
sufficient to prove my points. These are not full benchmarks since that isn’t
necessary for an article; they prove the point – sequential is usually faster
than the parallel version, etc.

There are seventeen points in the first two articles. Not one person has ever
said, “Hey Ed, that’s not true.” The points are accurate. There is no B.S. in
any of the articles. I may not have the eloquent style of a professional
author (yes I am a little blunt, what else do you expect from a programmer)
but I did the best I could. If you want to throw eggs at them, fine. At least
be specific about which point you think is wrong.

Intel has TBB. Microsoft TPL. If Java wants a parallel engine then they should
have copied the others. Using an academic centric product that is based on
dyadic recursive division is not the way into the parallel future for Java.

------
616c
So Scala or Clojure it is? Honestly, I am starting to learn Java as a very
amateur programmer and this is over my head.

Are the other JVM languages actually doing better as they were architected
differently from their core, the models for parallelism and/or concurrency is
different, both? I would love to hear comments from those more educated than I
in JVM esoterics (although I would say the money involved it is worth
knowing).

~~~
ecopoesis
By default, Scala's parallel collections use fork/join on JVMs > 6, so using
Scala probably isn't going to change much for you.[1]

Also, note that this guy's company makes software that directly competes with
the JVM's fork/join framework, so he's not exactly an unbiased source.[2]

[1] [http://docs.scala-lang.org/overviews/parallel-
collections/co...](http://docs.scala-lang.org/overviews/parallel-
collections/configuration.html)

[2]
[http://www.coopsoft.com/Products.html](http://www.coopsoft.com/Products.html)

~~~
raspasov
Very good point, they also have a VERY cool website
[http://www.coopsoft.com/](http://www.coopsoft.com/)

~~~
sciurus
According to the meta tag, it's generated with Microsoft FrontPage 5.0.

~~~
raspasov
WOW :) Haha, that's way too funny, I made my first website with Frontpage
around year 2000.

------
0x0
I am shocked he didn't write "java™.util.stream"

