A bird's-eye view of computer-Go programming: a large part of what a Go program
does will probably be some sort of analysis of a deep tree of possible moves,
involving the exploration of millions of possible positions. The guts of this
should be as optimal as possible. A slower language such as Ruby or Perl is not
a good fit for such efforts - but that's a strawman argument, of little
practical relevance.
Higher-level optimizations can provide far more remarkable speed gains than the
choice of implementation language. When Lukasz Lew wrote libego, I believe he
recast the algorithms a few times in order to extract maximum performance, as
he discovered more about how his chosen language ( C++ ) is compiled into
assembler, and how that affects performance. Improvements to move ordering
algorithms can enable reductions in the breadth of trees, which greatly reduce
the size of the tree. Improvements in the quality of playouts result in vast
improvements to the quality of the evaluations, which can lead to reductions in
evaluation times. Several have noted that fast mersenne twister algorithms
improve the speed and quality of "random" playouts. Ways to refactor, to
incorporate higher-level knowledge, and otherwise increase the performance of
our programs will be discovered as we learn more about the demands of computer
Go. Better algorithms can improve program
performance by factors of tens, hundreds, even thousands. Some future
improvements will surely lead to increases of hundreds of elo points in
ratings, given the same hardware and implementation language. Some of us will
find ways to wring lots of elo points from multiple processors. Some of these
improvements may be much more easily expressed in higher-level languages than
in C.
I cut my teeth on FORTRAN and C and assembler, having written hundreds of
thousand lines in such languages, as well as piles of scripts in Perl, Ruby,
Python, R, and other languages. I've chosen to study Lisp again ( which I last
tinkered with in the 70s ) because I think I see interesting ways to take
advantage of the unique properties of Lisp. I could write C equivalents to
these capabilities - but I'd rather use a language where where my ideas are a
more natural fit. There's a saying that any sufficiently
sophisticated program will eventually include a buggy implementation of the Lisp
eval loop. My efforts may use C libraries for some speed-intensive task; it may
be all Lisp; too early to make that judgment.
When humans explain how they play Go, their algorithms rarely require the
investigation of millions of potential positions. A good program need not
follow the same methods as a good human player, but it just might be that human
play still offers a few very high-level optimizations. Fuel for thought.
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs _______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
