[computer-go] gpugo

[Gunnar Farnebäck]

Florian Erhardt wrote:
 > Hello !
 >
 > My name is Florian Erhardt, I am a bachelor student of computer sciences
 > and am in the process of optimizing libEGO for gpgpu. For now I
 > implemented the SFMT (even I can do copy and paste) on the gpu and am
 > now atomizing the MC to be done by the gpu. If everything works as I
 > planned it, I'll  have a releasable program in a few months (I still
 > have to learn lots about parallelizing, gpu programming and programming
 > in general [maybe leaning about genetic algorithms can't hurt either -
 > The RAVE algorithm is more like a genetic algorithm - Right ?] - and I
 > have to go to university :-) ).
 >
 > For now I'm using a  MC-engine with UCT, trying out how much patterns
 > and other things might make the results better.
 > Now as I understand it, using patterns, groupstatus, ... during the
 > MC-playout makes the results from the playout more meaningful (stronger
 > - 30k instead of random), so if I would make the playout with a small
 > engine (the easiest way to use the power of the gpu) the result should
 > be more meaningful too. Has anyone done any test like that (like use
 > gnugo level 0 instead of an MC-playout) ? Does anyone have a
 > minimalistic non-MC go engine I could look at ? One more thing - has
 > anyone tried using quasi-MC for go ?

I don't want to discourage you but this doesn't match my experience
of GPGPU from other applications, nor my experience of MC go.

First, using GNU Go level 0 for playouts is pointless. It's too slow
and deterministic for an MC approach and too slow and weak for a
non-MC approach.

Second, as other people have pointed out, the strength of individual
playouts does not have a strong connection with the strength of an UCT
program. I would go as far as to conjecture that it's entirely
irrelevant. (Patterns are indeed useful but for other reasons than
playout strength.)

Third, if you want to get any kind of speed from the GPU you must go
massively parallel. Think in terms of a big texture filled by lots of
go boards side by side and try to operate on all of them
simultaneously in a reasonably uniform manner. Forget everything about
group status and other complicated concepts. If you can just implement
an UCT engine with uniformly random playouts on the GPU and get
significantly better performance than on CPU it's a major achievement
in my book.

/Gunnar