[Haskell-cafe] Re: Go Haskell!
claus.reinke at talk21.com
Wed Mar 18 12:49:08 EDT 2009
>I finally got around to making my code for random Go playouts available.
> Here it is:
Cool!-) To reciprocate, I've temporarily put a snapshot of my code here:
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!-)
> 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.
> 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?-):
>> [ 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.
More information about the Haskell-Cafe