Version française
Home     About     Download     Resources     Contact us    
Browse thread
We should all be forking
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] We should all be forking


On Tue, 5 Jun 2007, Jon Harrop wrote:

>
> Following on from our "why not fork" discussion, here is my most elegant
> concurrent ray tracer written in vanilla OCaml.
>
> This program simply runs four processes (forking off three) in parallel to
> improve performance when 2-4 CPUs are available (increase "d" if you have >4
> CPUs).
>
> This isn't as sophisticated as the JoCaml version but it does double
> performance (taking the time down from 4s to 2s) on my dual-core machine,
> making it faster than any language that uses a concurrent GC. I don't know
> about you guys, but this is a complete revelation for me!

This actually doesn't surprise me.  Big linear algebra problems- like ray 
tracing- are almost embarassingly parallel.  This is why the supercomputer 
market died a decade and a half ago- it was just too easy to take the 
problems supercomputers were designed to handle and spread them out over 
an cluster of workstations or pcs.  What needs to be shared in the ray 
tracing example?  The model, obviously.  And the results have to be 
collected.  And what subset of the problem (which collection of rays) need 
to be worked on.  I note that the big-iron database machine (aka 
mainframe) market is alive and well.  Some problems don't parallelize 
quite so easily.

My point here is to caution against making too much soup from this lone 
oyster.  Simply because this program, and a large class of other programs 
like it, parallelize easily, doesn't mean all will.

On the other hand, for programs that do parallelize this way, JoCaml looks 
like a wonderful gift.

Brian