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 _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
