[Haskell-cafe] Re: GHC threads and SMP

[Paul L]

> Donald Bruce Stewart wrote:
> > Hmm, any change with -O2? Is the optimiser changing the code such that
> > the scheduler doesn't get to switch threads as often? If you change
> > the thread scheduler switching rate does that change anything?

The behavior only appears when -O or anything greater than -O is
applied. It does appear to be that thread switching isn't happening as
often as I wanted it for the Prime number example.

On 7/10/07, Simon Marlow <simonmarhaskell at gmail.com> wrote:
>   (a) the child threads aren't doing any work, just accumulating a large
>       thunk which gets evaluated by the main thread sequentially.

this is unlikely, as it's using IO monad, which forces evaluation for
things like array updates.

>   (b) you have a sequential dependency somewhere

also unlikely, because without -O it'd use two OS threads.

>   (c) tight loops that don't allocate don't give the scheduler a chance
>       to run and load-balance.
>
> I doubt that (c) is a problem for you: it normally occurs when you try to use
> par/seq and strategies, and are playing with parallel fibonacci.  Here you are
> using forkIO which definitely allocates, so that shouldn't be a problem.

it's possible that the thread doesn't allocate much after the optimization.
In the Prime number example, every thread actually spawns a new thread
before doing its own work, and the work it does (function remove')
will not spawn
new threads. It is very likely that remove' is optimized to a simple
loop as it's tail recursive. So each thread has little chance to give
other thread a chance to run if it doesn't switch during thread
spawning.

Compare this to the QSort example, where each thread spawns a new
thread to sort half of the array after splitting, and continue to sort
the other half in the original thread. This could explain the
difference.

Indeed, after I insert a yield after "spawnRemover (i + 1)", it now
happily crunches number on both CPUs. Thank you both for the
suggestions!

Regards,
Paul L