Harald Korneliussen wrote: > Some thinking out loud here on the topic of languages and efficiency: > > I'd like to know how well MoGo would have played if you let it think > for a week for every move. Only it seems to me that is not possible, > because I don't think MoGo will run for a week without crashing. > Crazystone also crashes quite a lot, if I understand the comments in > KGS logs correctly. > Memory is an issue with these programs, since they build tree's and maintain them in memory. So none of these programs can think for more than a few minutes per move.
If we pretend that memory is adequate and mogo could run for a week per move, it would play an incredibly strong game. I did a study which showed a linear increase in playing strength per doubling of speed with my weaker program Lazarus. I have less data with 19x19 but we saw the same dramatic improvement. I would feel confident in saying that at 9x9 Mogo would give several Dan players a difficult game and at 19x19 playing at one week per move it would be playing at least 2 or 3 Dan. I have no way to back up this claim so don't flame me. Because of the nature of the algorithm, it will always play stronger when given more time (if there is enough memory to grow bigger tree's.) > You got to wonder. One thing is move quality reduced by traditional > bugs, but when the program periodically is forced to restart and throw > away its calculations because of a crash, it seems to me there's a lot > to gain from using a more reliable programming language. > I was not aware that these programs were unstable. I looked at the highest rated program currently on the active list for 9x9. It is greenpeep0.5.1 and it has played 225 games. It has not lost a single game against player lower rated less than 2077. It has lost only 4 games against players rated between 2077 and 2472 (4 out of 96 against very strong opponents.) It's worst result is against another program nearly as strong, Crazy Stone. It lost 10 out of 28 games. >From this record, if the program is buggy I wish my program was buggy too. If there are any bugs causing it to lose games as a result of crashing, then even if they were fixed, it could not improve the results very much. Of course if there are performance bugs then fixing those bugs would be useful, but it doesn't make too much sense to fix performance bugs by moving to a lower performance language. > Also, do we really know all we need to know about algorithmic > approaches? If yes, then it's about implementing them as efficiently > as possible, to maximise the number of playouts per second... C or C++ > is probably a good choice. But if not, it probably matters a lot more > about how flexible it is, how easy it is to try out different > approaches. If it runs ten times as slow as the C version, why not > just let it think for ten times as long? That is affordable when > experimenting, right? > Most of the improvement has indeed come from making these programs smarter, even though it has cost some performance in raw numbers. However it's important to note that people have reported improvements that slowed the program down too much. This is not a difficult principle to understand. Make the trade-off that works the best. You will never find an algorithm so smart that there is no performance cost associated with it and neither will you get it to run so fast that you don't need it to be smarter. All you have to do is look to see what the best programs are doing. They have really smart algorithms and they are running on fast computers and multi-processors and they are written in C. No big surprise. - Don > But I have to admit, I don't know exactly how I'd go about > implementing a transposition table in Haskell :-/ Perhaps I'll try for > a libEGO binding, then at least if there are stability problems, I can > blame someone else ;-) > _______________________________________________ > 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/
