From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Faking concurrency using Unix forks and pipes (ray tracing results)
Date: Mon, 4 Jun 2007 11:56:15 +0100 [thread overview]
Message-ID: <200706041156.16521.jon@ffconsultancy.com> (raw)
I just got a first working version of .NET style asynchronous invocation
working in OCaml using process forking.
The following OCaml function forks a new process and computes "f x" in that
process, returning a function that blocks and returns the result using
marshalling.
let invoke (f : 'a -> 'b) x : unit -> 'b =
let input, output = Unix.pipe() in
match Unix.fork() with
| 0 ->
Unix.close input;
let output = Unix.out_channel_of_descr output in
Marshal.to_channel output (try `Res(f x) with e -> `Exn e) [];
exit 0
| _ ->
Unix.close output;
let input = Unix.in_channel_of_descr input in
fun () ->
match Marshal.from_channel input with
| `Res x -> x
| `Exn e -> raise e
This function tries to account for reraising exceptions on the parent process
but that is untested.
You can write a higher-order "map" function in terms of invoke like this:
let ( |> ) x f = f x
let map (f : 'a -> 'b) a : 'b array =
Array.map (invoke f) a |>
Array.map (fun f -> f())
When you apply this map to an array, a new process is forked for each element.
As forking is time consuming, you should only apply this to short arrays.
The performance characteristics of this approach are very interesting.
Firstly, I can observe doubled performance on my dual core by invoking two
simple but CPU-intensive operations concurrently:
map fib [|43; 43|]
However, performance is easily degraded using this approach, partly because
forking is expensive but also because of other effects that I do not yet
understand. My original benchmark summed the elements of an array using
fold_left. For some reason, this is extremely inefficient, as if the entire
array is copied.
Anyway, this function is so simple that it took no time to work it into my ray
tracer benchmark. The benefits of concurrency on my dual-core system reduce
the time taken by OCaml from 4s to 3s.
I'll try a concurrent F# version and see how it compares...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
next reply other threads:[~2007-06-04 11:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-04 10:56 Jon Harrop [this message]
2007-06-04 15:33 ` [Caml-list] " Jonathan Bryant
2007-06-04 15:39 ` Jonathan Bryant
[not found] ` <9b415f950706040850v586a285ax1448d23c0c78a375@mail.gmail.com>
2007-06-04 16:13 ` Jonathan Bryant
[not found] ` <9b415f950706040933r22e1560fhc088368ccb8444fa@mail.gmail.com>
2007-06-04 16:53 ` Jonathan Bryant
2007-06-04 18:00 ` Brian Hurt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200706041156.16521.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox