Advice wanted on parallel processing

[Colin Paul Adams]

>>>>> ">" == j waldmann <waldmann at imn.htwk-leipzig.de> writes:

    >> (I am not updating in place).  The move generator produces a
    >> new board for each move.

    >> Well, this is sound design, but current memory managers may not
    >> be up to it.  If you check the (board) game programming
    >> literature, you'll find that engine authors take great efforts
    >> to bypass automatic memory management (do all updates on the
    >> "current" board in-place, and write their own malloc/free for
    >> game tree nodes).

I know it.
In fact I wrote a program for this game about 10 years ago, in C++,
which did all updates in place.
It wasn't very good (although being the only one that implemented the
rules correctly - as far as I could tell - they are very complicated 
- was necessarily the best).
Now I want to have another go in Haskell. Reading about DPH inspired
me to give it a try, although I'm not attempting to use DPH
yet. Probably I was too naive thinking I was going to be able to
exploit parallelism without pain.

    >> This becomes even more important when trying to exploit
    >> concurrency.  In theory, that's all very nice (you can evaluate
    >> independent branches of the game tree in parallel) but in
    >> practice, you're doomed if your memory allocator/collector is
    >> still essentially single-threaded (that is, blocks all
    >> threads).

OK, that's interesting. GHC's collector is still stop-the-world at the
moment, right? I read in the recent paper that it is intended to try
to remedy that soon, in which case I can try again to see if that
improves matters.
-- 
Colin Adams
Preston Lancashire