<rwmjones>
and accessing the memory of another processor is possible, but much slower
<rwmjones>
yup
<tsuyoshi>
jeffsmac: yeah
<tsuyoshi>
I looked at that and jocaml and I didn't really understand either of them at first glance
<rwmjones>
you might want to stick to OCamlMPI - simple and crude, but it will let your program scale over clusters which exist now
joshcryer has quit [Client Quit]
<tsuyoshi>
so maybe I should write an mpi map
<tsuyoshi>
I don't have any multi core machines but I do have a couple networks of mostly-idle linux desktops I could play with
bluestorm_ has joined #ocaml
Submarine has joined #ocaml
<flux>
tsuyoshi, anyway, I don't think for most pmap purposes you should fork right there, but instead fork beforehand a set of worker processes..
<flux>
tsuyoshi, perhaps only one for each available core
<flux>
but yes, the capability to get real concurrency is nice
<flux>
you still might want to use threads, though
<flux>
or atleast I'd like to see a nice synchronous Event-module for caml for inter-process communication
<flux>
(I like the model a lot, and I don't think I'm even exploiting it to the max..)
JeffSmac has quit []
<tsuyoshi>
the problem with forking ahead of time is that then you have to marshall the argument data
<rwmjones>
tsuyoshi, what do you mean?
<tsuyoshi>
when you fork, all the data that is available to the parent process is copied to the child process
<rwmjones>
oh I see, yes
<rwmjones>
tsuyoshi, out of interest, what's this for?
<tsuyoshi>
if you fork at the start of the program, then generate some data, and then want to pass it to the children to work on, you have to copy it to children
<tsuyoshi>
oh, someone on the caml mailing list asked about it
<tsuyoshi>
I thought it was an interesting idea but nobody really had any code
<rwmjones>
I saw that - I was wondering what you're using it for ... number crunching?
<tsuyoshi>
I don't have any use for it personally
<tsuyoshi>
the only thing I'm coding right now is a data entry program
<rwmjones>
if you've got a lot of fixed (read-only) data then it's the way to go
<tsuyoshi>
rwmjones: would it work over nfs?
<rwmjones>
that's a very good question actually :-) the answer, I think, is yes it would, but you'd definitely want to check it out with a small sample first
<rwmjones>
I mean ... you can mmap files over NFS, and it's read-only so there are no locking/concurrency issues, so it _ought_ to work
<tsuyoshi>
oh ok.. so there's no locking
<rwmjones>
you can lock the shared file explicitly if you want, using ordinary Unix.lockf
<tsuyoshi>
hmm.. so it's read-only
<rwmjones>
but it shouldn't be necessary, right
<rwmjones>
you can actually do dangerous writes to the ancient heap ... _if_ you really know what you're doing
<rwmjones>
but it's a fast way to get segfaults if you're careless
<tsuyoshi>
so you can write?
<tsuyoshi>
could it be used instead of marshalling?
<rwmjones>
it actually is very close to marshalling
<rwmjones>
it won't work in a mixed 32/64-bit environment for that reason
<rwmjones>
it was basically designed to work on clusters of almost identical machines
<Submarine>
Astrée forks when it runs on multiprocessors.
<Submarine>
the painful thing is sending back the results through a pipe and marshalling
<tsuyoshi>
what are "ad-hoc polymorphic primitives"?
<tsuyoshi>
oh never mind, I just realized what he meant
love-pingoo has joined #ocaml
Oxylin has joined #ocaml
Oxylin has quit [Client Quit]
mikeX__ is now known as mikeX
shawn has quit ["This computer has gone to sleep"]
clog has joined #ocaml
cjeris has quit [Read error: 104 (Connection reset by peer)]
<tsuyoshi>
hmm.. I think I will go back to using a map instead of an array in the forking map
smimou has quit ["bli"]
smimou has joined #ocaml
smimou has quit ["bli"]
smimou has joined #ocaml
pantsd has joined #ocaml
shawn has quit ["This computer has gone to sleep"]