From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3LA9AZR009639
	for <caml-list@sympa-roc.inria.fr>; Thu, 21 Apr 2011 12:09:10 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAN0BsE0+3JIE/2dsb2JhbAClSHeIcLtvhXYEjiuEBQ
X-IronPort-AV: E=Sophos;i="4.64,250,1301868000"; 
   d="scan'208";a="97676952"
Received: from vs.philou.ch ([62.220.146.4])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Apr 2011 12:09:04 +0200
Received: from [192.168.1.120] (85-218-16-131.dclient.lsne.ch [85.218.16.131])
	by vs.philou.ch (Postfix) with ESMTPSA id 74EB12332DA;
	Thu, 21 Apr 2011 12:09:04 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Philippe Strauss <philou@philou.ch>
In-Reply-To: <4DAFE141.7080003@inria.fr>
Date: Thu, 21 Apr 2011 12:09:03 +0200
Cc: caml-list@inria.fr
Message-Id: <92C4117E-BEDE-4F60-8747-F3BA48A5034A@philou.ch>
References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr>	 <4D8BD02D.1010505@inria.fr>  <4D8C73C8.6020801@inescporto.pt> <1301055903.8429.314.camel@thinkpad> <341494683.237537.1301057887481.JavaMail.root@zmbs4.inria.fr> <4D8C944A.9060601@inria.fr> <4D8CB859.9040709@inescporto.pt> <4D8CDDCC.4010000@ens-lyon.org> <029701cbff90$7a874510$6f95cf30$@ffconsultancy.com> <FB4D44C8-1B8E-405B-9734-53CA3A9AE1AB@gmail.com> <76544177.594058.1303341821437.JavaMail.root@zmbs4.inria.fr> <4DAFE141.7080003@inria.fr>
To: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>
X-Mailer: Apple Mail (2.1084)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3LA9AZR009639
Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap?


Le 21 avr. 2011 à 09:48, Fabrice Le Fessant a écrit :

> On 04/21/2011 01:23 AM, Jon Harrop wrote:
>> The OCaml team at INRIA are not motivated to do this because it does not
>> constitute research, would probably make Coq slower and would burden them
>> with maintaining irrelevant features.
> 
> You think the programmers in the world that are only interested in
> floating-point intensive computations, with fine-grain concurrency, are
> a huge majority. I think they are not so many. Can we do a better job of
> quantifying this ?

me!

for audio DSP.