terry mcintyre wrote: > 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. This is obviously true and a well known principle, but when you compare languages for speed, the assumption is that you are using the same algorithms - anything else is just unfair.
When you talk about Lukasz Lew and his very fast implementation, you will notice also that he chose C to write his library. I don't think this is a wild coincidence. It's a mentality and Lukasz has the right mentality. The kind of person who writes such a library is concerned about each single percent of execution speed because he knows they add up. He is not going to immediately start the project with a stupid decision. If he were willing to do that, chances are good that he would be willing to take other non-optimal choices. Of course I'm not saying that you can't do what Lukasz did using a different language. You could start with any constraints you want and then be disciplined from that point on - but you wouldn't end up with the same amazing results Lukasz did. He could have chosen Ruby, a far more expressive language. Perhaps it it would be a better choice for him because Ruby's amazing freedom of expression would unlock his mind and let him soar to new heights, but somehow Lukasz suffered along in C. - Don > 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. > > > ------------------------------------------------------------------------ > Be a better sports nut! Let your teams follow you with Yahoo Mobile. > Try it now. > <http://us.rd.yahoo.com/evt=51731/*http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ> > > ------------------------------------------------------------------------ > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
