[Haskell-cafe] Parallel compilation and execution?

[michael rice]

Hi Alex,
I had previously looked at OpenMP (Fortran) and when I saw par and seq in Control.Parallel I got a sense of common terminology, sections of code that can be executed in parallel and sections of code that must be executed sequentially. I haven't looked at Control.Concurrent yet.
The original reason I took a look at Haskell (and Erlang) was multi-core CPUs were becoming common and I wanted to learn to take advantage of them, but Haskell's learning curve has been so steep I've been occupied with learning other aspects of the language and only now have turned again to try my hand at its parallelizing features.
Thanks,
Michael 

--- On Fri, 5/27/11, Alex Mason <axman6 at gmail.com> wrote:

From: Alex Mason <axman6 at gmail.com>
Subject: Re: [Haskell-cafe] Parallel compilation and execution?
To: "michael rice" <nowgate at yahoo.com>
Cc: "David Virebayre" <dav.vire+haskell at gmail.com>, haskell-cafe at haskell.org, "Daniel Fischer" <daniel.is.fischer at googlemail.com>
Date: Friday, May 27, 2011, 6:05 AM

Hi Michael,
OpenMP is a very different beast, and was developed to help get over the shortcomings that languages like C and FORTRAN have with respect to parallel and concurrent programming (pthreads were about all there was before OpenMP). OpenMP lets you specify regions of code that should be run in multiple threads at once, each with a unique ID.  Here is an example of (part of) a parallel merge sort I've been working on
static voidpmergesort(long int * in, long int * tmp, long int n, int nthread){    long int nhalf = n/2;
    if(n <= N_small)    {        insertsort1(in, n);        return;    }
    if(nthread > 1)    {        #pragma omp parallel num_threads(2)        {            if(omp_get_thread_num() == 0)                 pmergesort(tmp,       in,         nhalf, nthread>>1);            else pmergesort(tmp+nhalf, in+nhalf, n-nhalf, nthread>>1);        }    } else {        mergesort3(tmp,       in,         nhalf);        mergesort3(tmp+nhalf, in+nhalf, n-nhalf);    }
    merge( tmp, in, nhalf, n);}
The approach that Control.Concurrent takes is very different, preferring a style where the programmer says what things might be advantageous to run in parallel, but the runtime makes no guarantees that they will be, allowing the programmer to break work down into smaller chunks, and letting the runtime sort out which parts should be run concurrently. This allows for a much easier style of parallel programming, but is only really possible in a pure language like Haskell. 
On a side note, the Cilk language, which adds a small number of keywords like fork and sync to the C language takes an approach closer to what Control.Parallel does, but it's not a graceful, and IMO not as easy to use.
Hope that helps. I've been having a lot of fun over the last few weeks playing with OpenMP for a university assignment, and I've got to say I greatly prefer the haskell way of doing things.
Cheers,Alex Mason
On 27/05/2011, at 10:23, michael rice wrote:
Are the tools of Control.Parallel comparable to OpenMP?
Michael

--- On Thu, 5/26/11, michael rice <nowgate at yahoo.com> wrote:

From: michael rice <nowgate at yahoo.com>
Subject: Re: [Haskell-cafe] Parallel compilation and execution?
To: "David Virebayre" <dav.vire+haskell at gmail.com>
Cc: "Daniel Fischer" <daniel.is.fischer at googlemail.com>, haskell-cafe at haskell.org
Date: Thursday, May 26, 2011, 9:32 AM

Fair question. I copied the parallel version from:

http://www.haskell.org/ghc/docs/6.6/html/users_guide/lang-parallel.html
but pulled the non-parallel version from a text.
Michael

--- On Thu, 5/26/11, David Virebayre <dav.vire+haskell at gmail.com> wrote:

From: David Virebayre <dav.vire+haskell at gmail.com>
Subject: Re:
 [Haskell-cafe] Parallel compilation and execution?
To: "michael rice" <nowgate at yahoo.com>
Cc: haskell-cafe at haskell.org, "Daniel Fischer" <daniel.is.fischer at googlemail.com>
Date: Thursday, May 26, 2011, 8:56 AM



2011/5/26 michael rice <nowgate at yahoo.com>

Thank, Daniel

Multiple threads are in evidence in my system monitor, but I wonder why I'm getting two different answers, one twice the other. The first is the parallel solution and the second is the non.

Why do you add n1+n2+1 in the parallel program, but only n1+n2 in the non-parallel one ? 

Michael

===========
{-import
 Control.Parallel
nfib :: Int -> Intnfib n | n <= 1 = 1
       | otherwise = par n1 (pseq n2 (n1 + n2 + 1))                     where n1 = nfib (n-1)
                           n2 = nfib
 (n-2)-}
nfib :: Int -> Int
nfib n | n <= 1 = 1       | otherwise = nfib (n-1) + nfib (n-2)

main = do putStrLn $ show $ nfib 39

=============
[michael at hostname ~]$ ghc --make -threaded nfib.hs
[1 of 1] Compiling Main             ( nfib.hs, nfib.o )Linking nfib ...
[michael at hostname ~]$ ./nfib +RTS -N3204668309[michael at hostname ~]$ ghc --make nfib.hs
[1 of 1] Compiling Main             ( nfib.hs, nfib.o )Linking nfib
 ...[michael at hostname ~]$ ./nfib102334155[michael at hostname ~]$ 




-----Inline Attachment Follows-----

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110527/809a99b5/attachment.htm>