[Haskell-cafe] Re: Go Haskell!
dons at galois.com
Thu Nov 27 13:43:53 EST 2008
> >>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
> 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
> 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:
> forced me to move from functional to imperative arrays much sooner
> than I wanted, and due to
> 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)...
More information about the Haskell-Cafe