02/11/2009 10:09:50 AM EST

Multicore servers will face the demands of developers to replace network/LAN traffic by in-machine messages. So they will have to offer fine tuning tools for process and resource communication and prioritizing which are machine specific and OS native. Please understand that I am sceptical when we talk about Java using these interfaces as long as I do not see a valid USB library - maybe I missed there sth actual but the problems there where impressing me deeply. I think forking/unforking is only part of the problem and definetely the article does NOT describe a Java specific advantage through technology.

Germanythomas wellbrock

02/11/2009 03:45:21 PM EST

Avik Thanks for the article. It's interesting to see the Java fork/join, and contrast it with the Erlang approach. One question and one comment: Do you think Fibonacci is a good candidate for parallisation? Essentially you are doing almost double the processing effort to compute any given Fibonacci number, since the previous result is not re-used as per dynamic programming. I.e. the 2x speedup can be gained by using a better sequential implementaion. Putting aside the issue of the suitability of the Fibonacci example, I think some readers would be interested to see an Erlang solution to a parallel Fibonacci problem. It uses a parallel map implementation that I've mentioned here: http://21ccw.blogspot.com/2008/05/parallel-quicksort-in-erlang-part-ii.html, which is about 12 lines of code. And the implementaiton (without the threshold support): p_fib(0) -> 0; p_fib(1) -> 1; p_fib(N) -> [F1, F2] = pmap:pmap(fun p_fib/1, [N-1, N-2]), F1 + F2. Which basically maps a function over a list, and the function is evaluated in a separate Erlang process (NOT related to OS processes). To me this is a much simpler (and hence more reliable solution). YMMV Benjamin

United KingdomBenjamin Nortier