claus.reinke:
http://computer-go.org/pipermail/computer-go/2008-October/016680.html Interestingly, I did this a while ago. Here's my results:
$ ./Bench 1 100000 b: 14840, w: 17143 mercy: 67982 elapsed time: 3.42s playouts/sec: 29208
so, nearly 30k/sec random playouts on 9x9. That's using a hack that stops the game when the score is heavily in favour of one player, it drops to around 20k/sec with that turned off.
Nice!-) 20k playouts/sec (without the early cutoffs) is the rough number usually mentioned for these light playouts, reachable even in Java. My own Haskell code for that was a factor of 5 slower:-(
actually, that 5x is relative to jrefbot on my machine (Pentium M760, 2Ghz), which doesn't quite reach 20k/sec, so if your code would run at 20k/sec on my laptop, it would be 10x as fast as my bot:-(( Since you can't release your code, could you perhaps time the jrefbot from the url above on your machine as a reference point, so that I know how far I've yet to go? Something like:
$ time ((echo "genmove b";echo "quit") | d:/Java/jre6/bin/java -jar refbots/javabot/jrefgo.jar 20000) = E5
real 0m2.539s user 0m0.030s sys 0m0.031s
Btw, I just realised where my bot dropped from 5x to 8x: to work around
http://hackage.haskell.org/trac/ghc/ticket/2669
all my array accesses were wrapped in exception handlers, to get useful error messages while I adapted my code to the refbot spec..
That's not the only bug that got in the way:
http://hackage.haskell.org/trac/ghc/ticket/2727
forced me to move from functional to imperative arrays much sooner than I wanted, and due to
http://hackage.haskell.org/trac/ghc/ticket/1216
I did not even consider 2d arrays (the tuple allocations might have gotten in the way anyhow, but still..).
What do those folks working on parallel Haskell arrays think about the sequential Haskell array baseline performance?
Try using a fast array library like uvector? (With no serious overhead for tuples too, fwiw)... -- Don