From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oliver@first.in-berlin.de>
Delivered-To: caml-list@yquem.inria.fr
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by yquem.inria.fr (Postfix) with ESMTP id C714CBC48
	for <caml-list@yquem.inria.fr>; Sun, 10 Apr 2005 14:25:13 +0200 (CEST)
Received: from first.in-berlin.de (dialin-145-254-055-051.arcor-ip.net [145.254.55.51])
	by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3ACPCdk012603
	for <caml-list@yquem.inria.fr>; Sun, 10 Apr 2005 14:25:13 +0200
Received: by first.in-berlin.de (Postfix, from userid 501)
	id 73A35D4E4F; Sun, 10 Apr 2005 11:59:53 +0200 (CEST)
Date: Sun, 10 Apr 2005 11:59:53 +0200
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Raising an old issue : true concurrency in OCaml [Xavier, Damien, any]
Message-ID: <20050410095952.GA472@first.in-berlin.de>
References: <20050407214731.E31541C00085@mwinf1201.wanadoo.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050407214731.E31541C00085@mwinf1201.wanadoo.fr>
User-Agent: Mutt/1.5.6i
X-Miltered: at concorde with ID 42591B28.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 ocaml:01 damien:01 low-level:01 ...:98 ...:98 parallelism:01 parallelism:01 wrote:01 compile:01 kernel:01 
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr
X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO 
	autolearn=disabled version=3.0.2
X-Spam-Level: 

On Thu, Apr 07, 2005 at 11:47:46PM +0200, Yoann Fabre wrote:
[...]
> My point is the following (let's be blatant): I'm afraid any pure-OCaml
> program will be limited to at most 50% of the CPU power on about 50% of the
> machines in the next five years ; and probably 25/30% on the remaining 40%
> of medium to high-end machines.
[...]

Maybe I'm not on the right track, but do you speak about
multiprocessor machines?
Isn't it the job of the system kernel to provide parallelism
to your application?
Why should the user do coding low-level hardware-stuff in the
user-space programs?  This does not make sense to me.

The OS should be able to hide special treatment of multiprocessor
architectures or CPU-internal modifications from the user and
do all this parallelism stuff transparently.

On Linux for example: don't forget to compile your kernel
with SMP-options and so on.

So, if I've overseen something, let me know it.


Ciao,
   Oliver