> I do not understand why they run out of memory in such a short time. E.g. > MoGo calculates 1100 Episodes/sec on 19x19. If one assumes 1 episode is 400 > moves, its max. 440 KPositions/sec. > [...] In my paper-design 200 > MBytes should be enough to run practically "forever".
In fact in MoGo, for each node we keep an "urgency" array which has the same size as the go board. It is un-usefull for current UCT, but MoGo has been designed not only to do UCT, and to allow a lot of modifications. There are also other informations kept in the nodes. So a node is about 1 kbytes in MoGo. I know this is far from efficient, but this is not a problem for short games, and we prefered to have an evolutive architecture. This can be improved taking some time :). > Note: If one uses for each small chunk of memory malloc() there is a > considerable overhead. With STL it gets worse. But STL is anyway no option > for a speed and memory critical programm. It should be relative trivial to > write an efficient memory handler. I agree, but, as we all have limited times, you have to choose where you spend your time. As the memory is not a problem for short games, it was not an issue, and we never spent time on this. Sylvain _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
