== j waldmann waldm...@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,
I've just managed to build ghc 6.11 (Thanks Simon).
I did this for two reasons, one of which is I want to try to improve
the speed of the AI for the Chu Shogi program I am writing by making
use of parallel processing. I have a 4-core Xeon runing Fedora Linux
10 (AMD64).
I have a repeatable
Am Mittwoch, 18. März 2009 15:28 schrieb Colin Paul Adams:
I've just managed to build ghc 6.11 (Thanks Simon).
I did this for two reasons, one of which is I want to try to improve
the speed of the AI for the Chu Shogi program I am writing by making
use of parallel processing. I have a 4-core
Daniel == Daniel Fischer daniel.is.fisc...@web.de writes:
Daniel generate_moves_for_piece produces a list. rwhnf forces
Daniel this list enough to see if it's [] or (_:_) (rwhnf x = x
Daniel `seq` ()), that doesn't get enough work done in each
Daniel thread to compensate the
On 2009 Mar 18, at 16:34, Colin Paul Adams wrote:
The one routine that stood out was this one (about 35% CPU time, with
0% attributed to children):
-- | Value of one rank of the board
rank_value :: (Int, Array Int Square) - Int
rank_value (rank_coord, rank') = sum (map (cell_value rank_coord)
Brandon == Brandon S Allbery KF8NH allb...@ece.cmu.edu writes:
The array has 12 elements.
Brandon How many times do you call it? Perhaps the real
Brandon optimization you need is to memoize.
Very many times indeed. But it is a different array on most occasions
(I am not updating
On 2009 Mar 18, at 16:59, Colin Paul Adams wrote:
Brandon == Brandon S Allbery KF8NH allb...@ece.cmu.edu
writes:
The array has 12 elements.
Brandon How many times do you call it? Perhaps the real
Brandon optimization you need is to memoize.
Very many times indeed. But it is a
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
