[Haskell-cafe] Re: Go Haskell!

[Don Stewart]

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