<div dir="ltr">Hi,<div><br></div><div>Thanks for taking the time to reply.</div><div><br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Something I have noticed with fork/join is the absence of clear-cut and<br>
common motivating examples and use cases.<br>
</blockquote>
<br></span>
One realm is aggregate operations; many of the most common ones<br>
(map, filter, reduce, collect, etc) now (in jdk8) prepackaged in.<br>
Stream.parallel(). But also used by others for custom in-core BigData<br>
algorithms and the like. (Plus, the underlying work-stealing<br>
scheduler is useful in other contexts.)</blockquote><div><br></div><div>So using fork/join is one approach to implementing such algorithms. Another would be to use a threadpool, possibly even a work-stealing style thread pool from fork/join, but manage the problem decomposition and result aggregation yourself. This seems to be the approach taken by the GS-Collections framework whose benchmarks suggest is very competitive performance-wise to parallel streams and have a similar style of API. Can you be more specific about the benefits here? Perhaps there's something that GS-Collections has had to reimplement multiple times that you can point to in their architecture or source code that Streams are getting for free.</div><div><br></div><div>The other side of this coin is that whenever I've seen people deploy some kind of big-data algorithm a significant problem isn't the computational part of that algorithm as much as it is querying the data from an external source which may involve I/O.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">everytime I try to fit a parallel programming problem into the fork/join<br>
model in my head it doesn't seem to offer me much over the ability to run a<br>
series of parallel threads.<br>
</blockquote>
<br></span>
Right. The main reason FJ exists in the JDK is to provide a framework<br>
for developing portable general-purpose versions of such programs,<br>
that includes ways of controlling how many threads are used,<br>
expressing and managing granularity thresholds,  load<br>
balancing when some cores are busy doing other things,<br>
nested parallelism, combining/reducing results,  and so on.<br>
<br>
Some people who don't care about any of these issues, and are<br>
content with ad-hoc programs that run well on particular computers<br>
don't have much motivation to use FJ. On the other hand, FJ can help<br>
in the discovery of parallel techniques by encouraging design<br>
via structured parallel divide-and-conquer, which is often a<br>
productive approach.<br></blockquote><div><br></div><div>Its perfectly understandable to want to provide a general framework here and I'm sympathetic to these motivating concerns, but I'm asking about which situations where you think delegating these responsibilities to the framework makes things sense over managing them by hand. Often people try to fit the wrong type of problem into a framework and its harder to manage the impedance mismatch than solve the problem.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Again I'm not trying to be too negative on F/J here as much as satisfying my curiosity and making sure that I'm not missing something in my understanding.</div><br><div class="gmail_signature"><div dir="ltr"><div><div>regards,<br><br></div>  Richard Warburton<br><br></div><div>  <a href="http://insightfullogic.com" target="_blank">http://insightfullogic.com</a><br></div><div>  <a href="http://twitter.com/richardwarburto" target="_blank">@RichardWarburto</a><br></div></div></div>
</div></div></div></div>