caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Eray Ozkural <examachine@gmail.com>
To: Rich Neswold <rich.neswold@gmail.com>
Cc: Goswin von Brederlow <goswin-v-b@web.de>,
	"caml-list@yquem.inria.fr" <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Smart ways to implement worker threads
Date: Sat, 17 Jul 2010 20:53:20 +0300	[thread overview]
Message-ID: <C749A998-D8DE-474F-945C-96C4628F73F6@gmail.com> (raw)
In-Reply-To: <AANLkTinJbOtdS-BT5Cma9hwzsPDEOuMmUCl5FPvVfia-@mail.gmail.com>

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


  reply	other threads:[~2010-07-17 17:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-14 16:09 Goswin von Brederlow
2010-07-15 15:58 ` [Caml-list] " Rich Neswold
2010-07-15 16:19   ` David McClain
2010-07-15 17:16   ` Ashish Agarwal
2010-07-15 18:24   ` Goswin von Brederlow
2010-07-15 18:37     ` David McClain
2010-07-15 18:40     ` David McClain
2010-07-15 19:56     ` Rich Neswold
2010-07-16  4:02       ` Goswin von Brederlow
2010-07-16  4:23         ` Rich Neswold
2010-07-16 13:02           ` Goswin von Brederlow
2010-07-16 14:40             ` Dawid Toton
2010-07-16 16:18             ` [Caml-list] " Rich Neswold
2010-07-17 17:53               ` Eray Ozkural [this message]
2010-07-20  4:54             ` Satoshi Ogasawara
2010-07-17 18:34         ` Eray Ozkural
2010-07-17 19:35           ` Goswin von Brederlow
2010-07-17 22:00             ` Eray Ozkural
2010-07-15 16:32 ` Romain Beauxis
2010-07-15 17:46   ` Goswin von Brederlow
2010-07-15 18:44     ` Romain Beauxis
2010-07-16  3:52       ` Goswin von Brederlow
2010-07-16  4:19         ` Romain Beauxis
2010-07-16 13:05           ` Goswin von Brederlow
2010-07-16 13:20             ` Romain Beauxis
2010-07-17  9:07               ` Goswin von Brederlow
2010-07-17 13:51                 ` Romain Beauxis
2010-07-17 14:08                   ` Goswin von Brederlow
2010-07-17  9:52 ` Goswin von Brederlow
2010-07-17 14:20   ` Romain Beauxis
2010-07-17 15:52     ` Goswin von Brederlow

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=C749A998-D8DE-474F-945C-96C4628F73F6@gmail.com \
    --to=examachine@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=goswin-v-b@web.de \
    --cc=rich.neswold@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).