Advice wanted on parallel processing
Colin Paul Adams
colin at colina.demon.co.uk
Thu Mar 19 02:35:28 EDT 2009
>>>>> ">" == 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
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
More information about the Glasgow-haskell-users