Re: [computer-go] 9x9 study rolloff
Hi, With such a large number of playouts, the tree size limit (and so heavy pruning) is certainly a possible hypothesis. The simplest way to test it would be to run the same MoGo_17 or _18 with a much bigger tree (taking more memory). --collectorLimitTreeSize is by default 40 (number of nodes). If you want to increase beyond 100, you should also add --limitTreeSize 200 (this limitTreeSize does not make much sense with the pruning, but it is a hard limit which, whatever happens, will not be reached... modulo bugs ;)) Sylvain 2008/1/31, Janzert [EMAIL PROTECTED]: I haven't seen anyone else mention this, although I may have missed it in one of the previous discussions. I find it pretty amazing that both Mogo and Fatman are leveling off at exactly, or almost exactly, the same number of playouts (i.e. Fatman lvl 14 == Mogo lvl 18 == 8388608 playouts). Could it simply be that they have run out of memory to build a larger tree and are starting to prune branches that would become critical if they had the space to explore them? Janzert ___ 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/
Re: [computer-go] 9x9 study rolloff
Janzert wrote: I haven't seen anyone else mention this, although I may have missed it in one of the previous discussions. I find it pretty amazing that both Mogo and Fatman are leveling off at exactly, or almost exactly, the same number of playouts (i.e. Fatman lvl 14 == Mogo lvl 18 == 8388608 playouts). Could it simply be that they have run out of memory to build a larger tree and are starting to prune branches that would become critical if they had the space to explore them? That could explain mogo and so could the floating point issue. But it doesn't explain FatMan, because there are still enough nodes in it's memory pool for this number of play-outs. - Don Janzert ___ 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/
Re: [computer-go] 9x9 study rolloff
I recently upped mine from 32 bit to 64 bit. Once I put more checks in my code, I found that stale data was getting reused. I may be an exception to the rule though because I've never implemented a way to clear out old search data. My engine is slow, so that's less of a problem in short CGOS games. On Jan 31, 2008 4:14 PM, steve uurtamo [EMAIL PROTECTED] wrote: how many bits are you guys using for your (presumably) zobrist hashes? just curious. :) s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, January 31, 2008 3:33:36 PM Subject: Re: [computer-go] 9x9 study rolloff Janzert wrote: I haven't seen anyone else mention this, although I may have missed it in one of the previous discussions. I find it pretty amazing that both Mogo and Fatman are leveling off at exactly, or almost exactly, the same number of playouts (i.e. Fatman lvl 14 == Mogo lvl 18 == 8388608 playouts). Could it simply be that they have run out of memory to build a larger tree and are starting to prune branches that would become critical if they had the space to explore them? That could explain mogo and so could the floating point issue. But it doesn't explain FatMan, because there are still enough nodes in it's memory pool for this number of play-outs. - Don Janzert ___ 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/ -- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ 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/
Re: [computer-go] 9x9 study rolloff
On Jan 31, 2008 4:31 PM, Don Dailey [EMAIL PROTECTED] wrote: FatMan doesn't use a hash table to represent the tree, it actually uses a tree with pointers and so on. For detection of repetition in the search part, FatMan uses a 64 bit zobrist key. How do you find a pre-existing node to point to without a hash table lookup? I view a hash table as a mapping between the zorbist key and the (pointer to) the node of interest. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 9x9 study rolloff
FatMan doesn't use a hash table to represent the tree, it actually uses a tree with pointers and so on. For detection of repetition in the search part, FatMan uses a 64 bit zobrist key. - Don steve uurtamo wrote: how many bits are you guys using for your (presumably) zobrist hashes? just curious. :) s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, January 31, 2008 3:33:36 PM Subject: Re: [computer-go] 9x9 study rolloff Janzert wrote: I haven't seen anyone else mention this, although I may have missed it in one of the previous discussions. I find it pretty amazing that both Mogo and Fatman are leveling off at exactly, or almost exactly, the same number of playouts (i.e. Fatman lvl 14 == Mogo lvl 18 == 8388608 playouts). Could it simply be that they have run out of memory to build a larger tree and are starting to prune branches that would become critical if they had the space to explore them? That could explain mogo and so could the floating point issue. But it doesn't explain FatMan, because there are still enough nodes in it's memory pool for this number of play-outs. - Don Janzert ___ computer-go mailing list computer-go@computer-go.org mailto:computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org mailto:computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20 ___ 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/
Re: [computer-go] 9x9 study rolloff
Sylvain, These 2 parameters are confusing to me. --collectorLimitTreeSize sounds like it limits the tree size to whatever your setting are, but so does --limitTreeSize. What is the difference between a tree and a collector tree? I assume the collector is a garbage collector of some sort?My guess is that the collector limit is the largest tree allowed after collection and the --limitTreeSize is how big it must get before collection? - Don Sylvain Gelly wrote: Hi, With such a large number of playouts, the tree size limit (and so heavy pruning) is certainly a possible hypothesis. The simplest way to test it would be to run the same MoGo_17 or _18 with a much bigger tree (taking more memory). --collectorLimitTreeSize is by default 40 (number of nodes). If you want to increase beyond 100, you should also add --limitTreeSize 200 (this limitTreeSize does not make much sense with the pruning, but it is a hard limit which, whatever happens, will not be reached... modulo bugs ;)) Sylvain 2008/1/31, Janzert [EMAIL PROTECTED]: I haven't seen anyone else mention this, although I may have missed it in one of the previous discussions. I find it pretty amazing that both Mogo and Fatman are leveling off at exactly, or almost exactly, the same number of playouts (i.e. Fatman lvl 14 == Mogo lvl 18 == 8388608 playouts). Could it simply be that they have run out of memory to build a larger tree and are starting to prune branches that would become critical if they had the space to explore them? Janzert ___ 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
