caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Frédéric Gava" <gava@univ-paris12.fr>
To: <caml-list@yquem.inria.fr>
Subject: Fw: [Caml-list] How INRIA people envision OCaml's parallel future?
Date: Thu, 23 Jun 2005 13:41:34 +0200	[thread overview]
Message-ID: <003701c577e8$82512080$0100a8c0@mshome.net> (raw)


----- Original Message -----
From: "Frédéric Gava" <gava@univ-paris12.fr>
To: "David MENTRE" <david.mentre@gmail.com>
Sent: Thursday, June 23, 2005 11:49 AM
Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future?


> Hello,
>
> >Good question that I did not considered when asking my own question.
> Thanks ;-)
>
> >Right now, I'm writing a user program (with Lablgtk2 user interface)
> >and a server program (network, file and databases I/O, lot of in
> >memory data structures, few computation intensive parts, mostly
> >algorithmic issues). On the user side, I see no real need of
> >parallelism, except if it can improve responsiveness (e.g. user
> >graphical front-end and back-end that interact with the server on the
> >network). On the server side, it is different. If I have a dual core
> >machine (and *I'm going to have* a 2- or 4-core machine), I would like
> >my server to reply as fast as possible to clients, which implies that
> >some tasks must be done in the background, with all the implied
> >synchronization issues.
>
> For tasks parallelism, you can try pGhc or Eden (but it is parallel
> extention of Haskell) or mobile haskell
>
> Herrmann  ( http://www.fmi.uni-passau.de/~hermann ) has also developp a
> tasks parallel extention of MetaOCaml using
> OCamlMPI.
>
>
> >As you see, my programmer profile is quite different from the expected
> >usage of BSMLlib (if I have understood BSMLlib description correctly):
> >no data parallel programming, rather control parallel programming.
>
> yes. Ok. You are in the case of tasks parallelism.
>
> You an try an interface between ocaml and OpenMM but without a parallel
GC,
> it seems (peraps ?) unsafe.
>
>
> >I'm not interested in THE parallel paradigm that will solve all
> >parallel programming issues.
> ok
>
> >After 50 years of research, no consensus
> >have emerged yet.
> Agree
>
>
> >That's said, it does not mean that OCaml should not provide tools to
> >improve the current state of affair. It is already doing that with
> >type inference, GC or sum types.
>
> >Programming parallel code with Posix
> >mutexes and threads is a nightmare.
> Agree, one of our parallel libraries (mspmllib) used massively those
> features and it is too hard to debug...
>
> >I have to say that I had a very
> >pleasant experiment with OCaml typed channels (aka Concurrent ML
> >channels). I'm just wondering if INRIA people consider that unknown
> >(to a wide public) constructs could be offered to ease concurrent
> >programming. And knowing that current ocaml cannot handle real
> >concurrent threads is a real concern.
> ok
>
> Frédéric Gava:
>
> ps: are you a researcher or an ingeneer ?
>



                 reply	other threads:[~2005-06-23 11:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='003701c577e8$82512080$0100a8c0@mshome.net' \
    --to=gava@univ-paris12.fr \
    --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;
as well as URLs for NNTP newsgroup(s).