Parallel Framework Shootout

The JVM concurrent (or parallel, I’m using these terms interchangeably although I’m aware they have subtly different meanings) worlds has been exploding with activity and innovations lately. It all started with the now veteran but extremely well designed java.util.concurrent package and more recently, we have seen Scala enter the fray with its Actor Model, Groovy with GPars and Doug Lea’s Fork Join Framework (PDF). Let me know if I forgot any.

I find all these frameworks intellectually interesting but I’m still not quite convinced that either of the incumbents is superior to java.util.concurrent (although if I had to pick one, it would probably be GPars). Interestingly, all these frameworks intend to simplify concurrent programming but a lot of these claims are going pretty much unchallenged, or supported by trivial exercises that are biased toward the framework’s own documentation.

I’m keeping my mind open but so far, I haven’t seen any blinding proof of either of these superiority claims. What I would really like to see is a non-trivial (i.e. requiring a few hundreds of lines of code to solve) concurrent problem written with java.util.concurrent and other parallel frameworks and a tentatively objective analysis of the pros and cons of each approach, on several axes: maintainability, testability, readability (more subjective), debuggability, performance, reliability, etc…

My gut feeling is telling me that while the Actor/Immutable/lock free model appears simpler, it also introduces a radical shift in the way you implement your solution that might be detrimental to its maintenance on the long run. At the end, you might end up with a simple locking model (since there are no locks) but at the expense of a more spaghetti-ish structure, since all these actors are now sending asynchronous messages to each other and retracing and debugging such a flow can be challenging.

Another gut feeling that I haven’t been able to shake off is the fact that the actor model introduces a single locking choke point (the inbox queue) while Java’s traditional locking approach allows you to position your lock wherever you want, and over an arbitrarily large (or small) portion of code. Determining such a locking can be challenging, but once you’ve solved that particular problem, it’s hard for me to imagine that there are more optimal ways of solving this problem.

I’m pretty optimistic about GPars because it’s built on top of java.util.concurrent while offering Groovy’s more compact syntax, which has the benefit of being simpler while very accessible for Java programmers.

The first step would be to come up with a non trivial problem that is a good match for a parallel implementation… Any suggestions?

From http://beust.com/weblog/2011/01/13/parallel-framework-shoot-out/