On Wed, Feb 13, 2008 at 09:59:28PM +0100, Gunnar Farnebäck wrote: > 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.
I admit I have no experience with GPU programming, so take all this with more than a grain of salt. Still, I would not even worry about patterns, UCT, or anything fancy, until I would have a fast and reliable MC-simulation code. And I would write the first (many?) versions on a normal PC, with all the good tools, just to understand the problem well. I would have them playing on cgos to see that they do all right. If I remember right, the ceiling is around 1500 ELO, which can be reached with something like 5000 simulations. The next step would be to rewrite everything for the GPU, sweet and simple. Then (and only then!) optimize a little bit (and only a little bit!). If you can not make that outperform LibEgo on a simple modern PC, there is not much point in trying to go further. It sounds like it would be a good idea to handle multiple MC simulations in parallel - if you have seriously vectorized bitmap operations, it might be quite effective. Once you have that, it should be (relatively!) trivial to make a UCT "main program" that pipes a number of positions into the GPU for MC simulations, and picks up the results. Once that plays well, it might make sense to consider moving some of that into the GPU, and/or improve the algorithms. But don't try to solve two problems at a time. If you want to play with the GPU, go for that with known algorithms. If you want to invent better ways to play go, don't waste your time programming fancy chips unless you know where you need the extra speed. Still, it sounds like quite a programming job! Wish I had the time and energy for that! - H -- Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
