How about expressing factorial like this?:

def fac(n: Int): Int = if (n == 0) 1 else mul (1, n)

def mul (from: Int, to: Int): Int = {
if (from == to)
return from
if (to – from == 1)
return to * from
val mid = (from + to) / 2
mul (from, mid) * mul (mid + 1, to)
}

Now fac(n) is recursively broken into independent subtasks, and should be an ideal candidate for fork join. For optimal performance it should fall back to sequential computation earlier than (to – from == 1).

NB: The mul function obviously makes some assumptions about the values of its parameters, but that’s ok if it is only used to help implement factorial. I haven’t tested it, so I can’t guarantee it compiles, let alone computes the correct result. But I think the general idea is clear at least

Ismael

[1] gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/forkjoin/
[2] http://www.javac.info/jsr166z/jsr166z/forkjoin/package-summary.html

All true (well, see next paragraph). The trouble is that algorithms which are intuitively parallelizable do not grow on trees. Worse, they tend to be a little more complicated than a simple factorial and fibonacci. I could have used them, but to do so would have detracted from the main point and made the final result a little less convincing. 14.6 vs 7.5 seconds is a pretty impressive comparison, and while the ratio would have been the same with a O(n) fibonacci, the difference would not have been so dramatic.

I actually disagree with you that the naive implementation of Fibonacci is not parallelizable. The fact that each calculation depends on two previous ones does not necessarily obviate the possibility, as shown by the fact that I did it. Doug Lea himself in explaining fork/join used pseudo-code algorithms which are assumed to be recursive in this fashion, despite the fact that they would share the same “unparallelizable” characteristics.

I think what you are seeing in Fibonacci is the issue of blocking recursion, each computation requiring its precedents and blocking until they are available. This is the problem which is solved by using actors in a linear chain. Each computation completes and then passes the result *specifically* to another Promise. Essentially, the actor strategy used transforms the Fibonacci computation from top-down to bottom-up. It’s still O(n!), but it no longer requires blocking on results which aren’t there yet. I didn’t go into this too deeply, but Apocalisp made it the main focus of his article. I refer you to his superior explanations.

thx for the step-by-step intro to the fork/join principle.

Like Jonathan, I think your choice of functions is a little bit misleading. Factorial is perfectly parallelizable by using the right algorithm. (You said that would require an ‘entirely different approach’, but isn’t using fork/join a different approach, as well?) . Admittedly the resulting definition of factorial is not as nice as your simple mathematical definition.

The fibonacci function however is in a very deep sense not parallelizable, since the last result depends on every single result before. Looking at the whole tree of computations your algorithm does, you can see that you call fib O(n!) times. Than you cut that in half by using two threads. You noted yourself that there are better algorithms: ‘Also, they’re fairly efficient in their own rights and thus see far less benefit from parallelization at the end of the day.’. That’s right, because you can’t reasonably make it parallel.

Don’t take me wrong, I know the purpose of this post was to explain fork/join but it leaves a thought of premature optimization to me.

Here’s a linear version which just remembers the last two elements:
def fib(i:Long):Long = {
def fib2(i0:Long,i1:Long,to:Long):Long =
if (to==1) i0 else fib2(i1,i0+i1,to-1)
fib2(1,1,i)
}

And here the parallelizable fac:
def fac(i:Int):Long = {
def inner(start:Int,length:Int):Long = {
val p = length/2
if (length == 1) start else inner(start,p) * inner(start+p,length-p)
}
inner(1,i)
}

http://www.erights.org/elib/distrib/pipeline.html
http://www.erights.org/elib/concurrency/refmech.html

Love the write-up, BTW.

Yes, you can split the factorial up into segments and compute them separately, but that’s an entirely different approach. I probably should have said “there is no way to modify *this* implementation…” The recursive factorial function only sees two numbers at a time, its current index and whatever the result is from its recursive invocation. A better (but far more complicated) implementation of factorial which could be parallelized using fork/join might look like this:

def fac(n: Int) = if (n < 2) 1 else {
{ (_:Int) * (_:Int) * (_:Int) } =<< promise(n) =<< fac(n – 1) =<< fac(n – 2)
}

At first glance, it seems like this is the same as your suggested implementation. However, we have introduced a very subtle problem here: overlapping sub-problems. Think about it, fac(n) requires fac(n – 1) and fac(n – 2). Moving on, fac(n – 1) requires fac(n – 2) and fac(n – 3). This naive implementation has increased the computational complexity from O(n) to O(n!). Aside from the neatly-recursive nature of that expression, we’ve created a mess.

In order to make the “piecemeal factorial” work, we either need to memoize the results (dynamic programming), or we need to try a different approach. Specifically, we could start from the bottom and work our way upwards to n. Unfortunately, this implementation would not be naturally recursive and thus, a little bit less subjectively elegant.

So unwinding that nice, long rabbit trail: yes, you’re correct, factorial *can* be computed in parallel. However, it can be very difficult to explain that in short, comprehensible examples without leading to a distracting tangent like the above. Besides, it was sort of nice and simple to explain operation reordering just using fac and fib, two functions that everyone understands intuitively.

It isn’t really, but the point there is that you don’t need to construct a hierarchy of promises. Because of monadic join, what you end up with is a single actor waiting for a value to which to apply the composed function.

The “bind” method that I’m referencing in my article is equivalent to liftM2 also. It’s a composition of apply and map, and apply is in turn just a composition of bind and map.

Have fun brushing up on your Haskell.