(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).
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).
That's language independent (it's a property of the run-time system).
Of course in a more declarative language it should be easier for the
compiler
to analyze the source code and replace malloc/free by something better
(no allocation by immediate re-use, or easy deallocation by some stack
regime).
J.W.
--
View this message in context:
http://www.nabble.com/Advice-wanted-on-parallel-processing-tp22580444p22591720.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
