From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 8B661BBAF for ; Fri, 25 Sep 2009 12:06:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AAF8zvErUnwdji2dsb2JhbACCIZhgAQEBCgsKBxEGuxuEHAU X-IronPort-AV: E=Sophos;i="4.44,450,1249250400"; d="scan'208";a="33506436" Received: from relay.pcl-ipout01.plus.net ([212.159.7.99]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Sep 2009 12:06:27 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8GAF8zvErUnw4R/2dsb2JhbACCIdQ7hBwF Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.pcl-ipout01.plus.net with ESMTP; 25 Sep 2009 11:06:26 +0100 Received: from [87.114.87.187] (helo=leper.local) by pih-relay04.plus.net with esmtp (Exim) id 1Mr7h4-0002H4-57 for caml-list@yquem.inria.fr; Fri, 25 Sep 2009 11:06:26 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures Date: Fri, 25 Sep 2009 11:17:41 +0100 User-Agent: KMail/1.9.9 References: <200909241409.56894.jon@ffconsultancy.com> <20090925.130721.70227045.garrigue@math.nagoya-u.ac.jp> <4ABC720A.7060706@inescporto.pt> In-Reply-To: <4ABC720A.7060706@inescporto.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909251117.42054.jon@ffconsultancy.com> X-Plusnet-Relay: d98459d09d0f3c1bf367a58b226ef99f X-Spam: no; 0.00; ocaml:01 run-time:01 parallelism:01 speedup:01 speedup:01 bounded:01 2009:98 frog:98 threads:01 wrote:01 caml-list:01 algorithm:01 loops:02 linear:02 algorithmic:02 On Friday 25 September 2009 08:32:26 Hugo Ferreira wrote: > Put it another way; if parallel/concurrent programming could be > easily used with a minimum of effort then I believe "most people" > would use it simply because it is available. Once your run-time supports it, you just need a library that farms tasks out to threads via queues and a lot of parallelism really is easy. > >... > > If I tell you that you just have to modify a bit your program to get a > > near linear speedup, then it looks great. But in practice it is rather > > having to rethink completely your algorithm, to eventually get a > > speedup bounded by bandwidth, and starting from a point lower than the > > original single thread program. > >... > > Rethinking our application/algorithmic structure may not be a real > deterrent. An application does not require parallel/concurrent > processing everywhere. It is really a question of identifying where > and when this is useful. Much like selecting the most "appropriate" > data-structure for any application. It's not an all or nothing > proposition. Right. Parallelizing programs generally consists of identifying a performance bottleneck via measurement and performing the outermost parallelizable loops in parallel. You can do many more clever things but they are far less common. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e