Browse thread
We should all be forking
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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