It does encourage me to take a shot at using the Event module.

One of the advantages of object orientation was that event-driven programming 
and concurrent processes would/could fit well.

Yet years later event driven programming exists mostly as the main loop of GUI 
libraries and implemented in cumbersome imperative languages. 

It has been suggested that traditional synchronization primitives are 
deficient. Like with message passing libraries it's too easy to write incorrect 
code with them (since they assume all programmers must be naive enough to still 
code in C.). I think it's so much easier to make a buggy implementation in 
posix threads that I advise against (having to) use it in any language.

In my experience with shared memory programming I found it a better option to 
write code in openmp. Charm++ like spawn directives aren't too bad either and 
they fit functional languages. 

I suppose with some compiler help we could have such parallelization; maybe 
just some camlp4 macros are enough. After all, it's not a bad idea to isolate 
synchronization in the program and I bet it can be done in a safe way. What 
would be needed to adapt the openmp idea to ocaml? Assuming we have proper 
multicore support (lock-free parallel garbage collector, real threads etc.)

Considering that architectural details cannot be so easily ignored on a 
multicore architecture I wonder how to do this best. Perhaps some way to 
specify fine-grain parallelism would be more flexible (like fine-grain kernels 
in cuda) I think architectural details would be important for parallel code 
optimizations.

We had used a thread/critical region based intermediate program representation 
for C but I think we could do better with functional  languages, towards a 
fully implicit parallel PL.

Of course there are various existing approaches to implementing explicit 
parallelism on top of ocaml. I wonder if the INRIA team would consider adapting 
those to a shared memory architecture. Short of the high technology we need 
(implicit parallelism) we can be satisfied with cool functional and 
architecture agnostic parallelism primitives.

So my wishlist is:

1) low level shared memory programming primitives and lang support
2) high level parallel programming facility that is completely independent of 
target architecture
3) implicit parallelism that uses an automatic parallelization approach

Cheers,

Eray

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Reply via email to