[Haskell-cafe] forkIO on multicore[MESSAGE NOT SCANNED]

[Duncan Coutts]

On Tue, 2008-12-23 at 18:27 +0000, Paul Keir wrote:
> Hi Duncan,
> 
> I'm following the story regarding (parallel) GC in this example
> with interest, but forgive me if I ask a more minor question
> regarding your modification of an extra parameter, "n", to
> "heavytask". Does this really help (to ensure that each core
> does work independently)? Surely, with fibs now described in a
> where clause, the "0:1:etc." form would not be shared among the
> (8) instantiations of "heavytask"?

Yes, that was the purpose of the modification, to ensure that the value
was not shared but calculated independently. I wanted to test speedup
with a trivially parallel workload.

If the value really is shared then there will necessarily be no speedup.
That is because the definition of this value does not use any explicit
parallelism and ghc does not do any automatic parallelisation. Demanding
the same evaluation from multiple threads just causes the other threads
to block awaiting evaluation.

> > heavytask m n = putMVar m $! (fibs !! 100000)
> >   where
> >     fibs = n : (n+1) : zipWith (+) fibs (tail fibs)

To get parallel speedup when evaluating a single value like this we need
a different definition. We could use IO threads with forkIO and explicit
shared variables or message passing. However since this is a pure
function a much nicer approach is to use a pure implementation using the
`par` operator:

http://darcs.haskell.org/nofib/parallel/parfib/Main.hs

-- parallel version of the code with thresholding
parfib :: Int -> Int -> Int
parfib n t | n <= t = nfib n
           | otherwise = n1 `par` (n2 `pseq` n1 + n2 + 1)
                         where n1 = parfib (n-1) t
                               n2 = parfib (n-2) t

Using `par` creates "sparks" which are even lighter weight than Haskell
IO threads. They are just values/thunks and get evaluated by a pool of
ordinary Haskell threads.

Duncan