Haskell for multicores

From HaskellWiki

Revision as of 02:03, 2 September 2008 by DonStewart (Talk | contribs)

(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)

GHC Haskell comes with a large set of libraries and tools for building programs that exploit multicore architectures.

This site attempts to document all our available information on exploiting such hardware with Haskell.

Throughout, we focus on exploiting shared-memory SMP systems, with aim of lowering absolute wall clock times. The machines we target are typical 2x to 32x desktop multicore machine, on which vanilla GHC will run.

1 Introduction
- 1.1 Further reading
2 Thread primitives
3 Synchronisation with locks
4 Message passing channels
5 Lock-free synchronisation
6 Asynchronous messages
7 Parallelism strategies
8 Data parallel arrays
9 Foreign languages calls and concurrency
10 Profiling and measurement

1 Introduction

To get an idea of what we aim to do -- reduce running times by exploiting more cores -- here's a naive "hello, world" of parallel programs: parallel, naive fib. It simply tells us whether or not the SMP runtime is working:

import Control.Parallel
    import Control.Monad
    import Text.Printf
 
    cutoff = 35
 
    fib' :: Int -> Integer
    fib' 0 = 0
    fib' 1 = 1
    fib' n = fib' (n-1) + fib' (n-2)
 
    fib :: Int -> Integer
    fib n | n < cutoff = fib' n
          | otherwise  = r `par` (l `pseq` l + r)
     where
        l = fib (n-1)
        r = fib (n-2)
 
    main = forM_ [0..45] $ \i ->
                printf "n=%d => %d\n" i (fib i)

We compile it with the `-threaded` flag:

   $ ghc -O2 -threaded --make fib.hs
   [1 of 1] Compiling Main             ( fib.hs, fib.o )
   Linking fib ...

And run it with:

   +RTS -Nx

where 'x' is the number of cores you have (or a slightly higher value). Here, on a quad core linux system:

   ./fib +RTS -N4  76.81s user 0.75s system 351% cpu 22.059 total

So we were able to use 3.5/4 of the available cpu time. And this is typical, most problems aren't easily scalable, and we must trade off work on more cores, for more overhead with communication.