Re: [Caml-list] Teaching bottomline, part 3: what should improve.

[Brian Hurt <bhurt@janestcapital.com>]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 2157 bytes --]