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.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A8EBABC0A for ; Thu, 24 May 2007 15:40:33 +0200 (CEST) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4ODeWJg029720 for ; Thu, 24 May 2007 15:40:33 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id A5D90184; Thu, 24 May 2007 09:40:41 -0400 Message-ID: <465595CB.8030907@janestcapital.com> Date: Thu, 24 May 2007 09:40:27 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@inria.fr Subject: Re: [Caml-list] Teaching bottomline, part 3: what should improve. References: <1179871823.6966.78.camel@Blefuscu> <20070523185428.GA32681@furbychan.cocan.org> <4654959C.7040701@fischerventure.com> <200705232246.14189.jon@ffconsultancy.com> In-Reply-To: <200705232246.14189.jon@ffconsultancy.com> Content-Type: multipart/alternative; boundary="------------070609020707010906050605" X-Miltered: at concorde with ID 465595D0.003 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; threads:01 iter:01 parallelism:01 parallelism:01 iter:01 threads:01 pumps:98 pumps:98 wrote:01 wrote:01 caml-list:01 formulation:01 formulation:01 data:02 data:02 This is a multi-part message in MIME format. --------------070609020707010906050605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jon Harrop wrote: >On Wednesday 23 May 2007 20:27:24 Robert C Fischer wrote: > > >>...and locks and threads are not a viable long-term solution to the >>problem of concurrency in general. >> >> > >Absolutely, that's why we have parallel iter, map, fold etc. > > The problem is not so much expressing the parallelism (especially data-level parallelism), it's dealing with the consequences- especially the race conditions and deadlocks that result. How do you gaurentee that the function passed into the parallel iter, map, or fold is appropriately reentrant? >Functional programming is not a panacea. GUI programming is one application >area where functional programming, immutability and the parallelizable >constructs that I just mentioned are not so beneficial. > >To solve GUI programming you need different constructs (events, message pumps >etc.). > > > Yep. The advantage of data-level parallelism is that it scales with the amount of data. You can always use more processors simply by throwing more data at the program. The problem is that it is of limited applicability, and that a lot of problems don't fit well (or at all) in it. The advantage of event/message based parallelism is that it is more widely applicable, the problem is that it doesn't scale- if you write your ap with N threads, it'll use up to about N processors- but the N+1st processor will be useless. This is a problem because the current proper formulation of Moore's law is that the number of processors available is doubling every 18-24 months (maybe faster). Brian --------------070609020707010906050605 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jon Harrop wrote:

On Wednesday 23 May 2007 20:27:24 Robert C Fischer wrote:

...and locks and threads are not a viable long-term solution to the
problem of concurrency in general.


Absolutely, that's why we have parallel iter, map, fold etc.

The problem is not so much expressing the parallelism (especially data-level parallelism), it's dealing with the consequences- especially the race conditions and deadlocks that result. How do you gaurentee that the function passed into the parallel iter, map, or fold is appropriately reentrant?

Functional programming is not a panacea. GUI programming is one application 
area where functional programming, immutability and the parallelizable 
constructs that I just mentioned are not so beneficial.

To solve GUI programming you need different constructs (events, message pumps 
etc.).

Yep. The advantage of data-level parallelism is that it scales with the amount of data. You can always use more processors simply by throwing more data at the program. The problem is that it is of limited applicability, and that a lot of problems don't fit well (or at all) in it. The advantage of event/message based parallelism is that it is more widely applicable, the problem is that it doesn't scale- if you write your ap with N threads, it'll use up to about N processors- but the N+1st processor will be useless. This is a problem because the current proper formulation of Moore's law is that the number of processors available is doubling every 18-24 months (maybe faster).

Brian

--------------070609020707010906050605--