I finally got around to making my code for random Go playouts available.
Here it is:
http://www.haskell.org/~simonmar/goboard.tar.gz
Cool!-) To reciprocate, I've temporarily put a snapshot of my code here:
http://www.cs.kent.ac.uk/~cr3/tmp/SimpleGo.hs
I've not yet decided whether to be depressed or encouraged by the
timings;-) without mercy rule, your code simulates at about 17k/s runs
here, vs only about 3k/s for mine. There are some obvious aspects, such
as hardcoding the boardsize isn't quite as straightforward when GTP
allows to change it at runtime, but I don't think that explains the bulk
of the difference. I do hope there are lots of small things to learn (perhaps
you could summarize your findings in a performance tips paper?-), but
at first glance, I suspect the difference in approach: my early experiments
suggested that maintaining chains/strings wasn't going to be more efficient
than following the affected parts of strings when needed - but I didn't
think of representing strings as cyclicly referenced lists (which allows
for string merge in constant instead of linear time). Nice idea!-)
Thanks,
Claus
If someone were to make a nice library API on top of this and upload it to
hackage, I'd be delighted. Hack away.
A GTP interface would be useful, to allow playing against other bots.
Cheers,
Simon
Simon Marlow wrote:
Claus Reinke wrote:
Do you have an example of a mutable state/ IO bound application, like,
hmm, a window manager or a revision control system or a file system...?
If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still around?-):
http://computer-go.org/pipermail/computer-go/2008-October/016680.html
[ catching up with old haskell-cafe email ]
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.
Not bad, but probably I'd guess an order of magnitude worse than you can
do in tightly-coded C. The Haskell implementation isn't nice, as you
predicted. Also the code is derived from some non-free internal MS
code, so unfortunately I can't share it (but I could perhaps extract the
free bits if anyone is really interested).
W wins slightly more often I think because komi 5.5 on a 9x9 board is a
tad high.
It does parallelise too, of course:
$ ./Bench 8 100000 +RTS -N8
b: 14872, w: 17488 mercy: 67584
elapsed time: 1.00s
playouts/sec: 99908
though still room for improvement there.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
