[computer-go] Trying to understand speed metrics
Currently I only get about 19k playouts per second on a 2 core Core2Duo 2.3 GHz, on 9 line empty board. I started at about 55k playouts per second on one core (for a UCT search). So, David, what happens when you are supply useful information? People impose on you for even more... I have seen playouts/second numbers a few times, and I always have trouble relating them to what I am working on. Usually other engines are 100x faster than mine, but sometimes only 10x. :-) The 19K/sec speed represents the first time that any engine has claimed to be *less* than 5x faster than mine, accounting for a difference in hardware. So I want to make sure that I understand. I am trying to get a handle on how fast a Core2 Duo 2.3GHz is, and it turns out that there is a wide range. The benchmarks at http://www.cpubenchmark.net/cpu_list.php show several parts that might match, with ratings as follows: Intel Core2 Duo E6550 @ 2.33GHz = 1415 rating (higher is better) Intel Core2 Duo P8400 @ 2.26GHz = 1542 rating Intel Core2 Duo P7550 @ 2.26GHz = 1796 rating Is your chip one of these? And you are using both cores? Another thing I notice about my engine is that playouts/second drops as the UCT tree becomes larger. For instance, between 10K trials and 100K trials the rate drops by ~20%. Profiling shows that this is because longer variations spend more time in selectBest(), giveCredit(), progressiveWidening(), and other tree management routines. So, a few questions: 1) are your measurements also in the context of a UCT tree? 2) what slowdown do you observe as search progresses? Your answers will go a long way towards helping me to understand how a world-class engine performs. I appreciate that you help the community in this way. TIA, Brian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic komi at high handicaps
My suggestion is to modify a program such as fuego to follow one of the algorithms as suggested - then test it with a large sample of games. If How? At CGOS? Because i noticed that twogtp.pl says eg constantly that stop-0.4 wins of 0.5 while at cgos I see the opposite. Folkert van Heusden -- Feeling generous? - http://www.vanheusden.com/wishlist.php -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] MoGo policy: capture stones anywhere?
MoGo's playout policy (at one time) is given in section 3.2 of Gelly et al's paper, Modification of UCT with Patterns in Monte-Carlo Go: We describe briefly how the improved random mode generates moves. It first verifies whether the last played move is an Atari; if yes, and if the stones under Atari can be saved (in the sense that it can be saved by capturing stones or increasing liberties), it chooses one saving move randomly; otherwise it looks for interesting moves in the 8 positions around the last played move and plays one randomly if there is any; otherwise it looks for the moves capturing stones on the Go board, plays one if there is any. At last, if still no move is found, it plays one move randomly on the Go board. We've implemented much of this, which has made Orego considerably stronger. The problem is with this part: otherwise it looks for the moves capturing stones on the Go board Does this really mean traversing the entire board looking for captures? Doing so seems to create a catastrophic speed hit. Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo policy: capture stones anywhere?
If you maintain a list of strings ( connected groups ) of stones and their liberty counts - or perhaps the actual liberties - it should be fairly quick to find a string with just one liberty. In any case, if I read the explanation correctly, this happens infrequently, if several less-expensive tests fail; the cost would be amortized over many trials. Terry McIntyre terrymcint...@yahoo.com And one sad servitude alike denotes The slave that labours and the slave that votes -- Peter Pindar From: Peter Drake dr...@lclark.edu To: Computer Go computer-go@computer-go.org Sent: Monday, August 31, 2009 9:56:16 PM Subject: [computer-go] MoGo policy: capture stones anywhere? MoGo's playout policy (at one time) is given in section 3.2 of Gelly et al's paper, Modification of UCT with Patterns in Monte-Carlo Go: We describe briefly how the improved random mode generates moves. It first verifies whether the last played move is an Atari; if yes, and if the stones under Atari can be saved (in the sense that it can be saved by capturing stones or increasing liberties), it chooses one saving move randomly; otherwise it looks for interesting moves in the 8 positions around the last played move and plays one randomly if there is any; otherwise it looks for the moves capturing stones on the Go board, plays one if there is any. At last, if still no move is found, it plays one move randomly on the Go board. We've implemented much of this, which has made Orego considerably stronger. The problem is with this part: otherwise it looks for the moves capturing stones on the Go board Does this really mean traversing the entire board looking for captures? Doing so seems to create a catastrophic speed hit. Peter Drake http://www.lclark.edu/~drake/ ___ 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] Trying to understand speed metrics
I had similar trouble in the beginning trying to compare my results to published results, both for speed and win rates. I have an E6550 at 2.33 GHz. I'm using both cores. This is a UCT search, biased by the Many Faces of Go move generator, with fairly stupid playouts. Currently I don't expand a move at the leaf until it has been visited four times, but each playout starts again at the root. Otherwise I run out of UCT memory. I see a slight slowdown (9x9 board, move 3, to avoid my very very small opening book): 20K playouts @ 20.7 K/s 100K playouts @ 19.7 K/s 470K playouts @ 17.7 K/s I don't have access to a profiler now, but I think it spends about 30% of the total time in Many Faces' move generator. My early UCT tests, with simple playouts and 3x3 patterns and no progressive widening, and no Many Faces' help, ran at about 34K playouts per second on a single core of this same machine. Smarter search has reduced the speed over 3x. This early, fast version beat gnugo 31% of the time on 9x9 with 3 minutes per game. The current version beats gnugo 19x19 83% of the time with 10K playouts per move. I don't test any more against gnugo 9x9, but when I stopped, it was beating it 91% of the time with 5K playouts per move. (gnugo for me is always 3.7.10 level 10 with lots of time). David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Brian Sheppard Sent: Monday, August 31, 2009 11:24 AM To: computer-go@computer-go.org Subject: [computer-go] Trying to understand speed metrics Currently I only get about 19k playouts per second on a 2 core Core2Duo 2.3 GHz, on 9 line empty board. I started at about 55k playouts per second on one core (for a UCT search). So, David, what happens when you are supply useful information? People impose on you for even more... I have seen playouts/second numbers a few times, and I always have trouble relating them to what I am working on. Usually other engines are 100x faster than mine, but sometimes only 10x. :-) The 19K/sec speed represents the first time that any engine has claimed to be *less* than 5x faster than mine, accounting for a difference in hardware. So I want to make sure that I understand. I am trying to get a handle on how fast a Core2 Duo 2.3GHz is, and it turns out that there is a wide range. The benchmarks at http://www.cpubenchmark.net/cpu_list.php show several parts that might match, with ratings as follows: Intel Core2 Duo E6550 @ 2.33GHz = 1415 rating (higher is better) Intel Core2 Duo P8400 @ 2.26GHz = 1542 rating Intel Core2 Duo P7550 @ 2.26GHz = 1796 rating Is your chip one of these? And you are using both cores? Another thing I notice about my engine is that playouts/second drops as the UCT tree becomes larger. For instance, between 10K trials and 100K trials the rate drops by ~20%. Profiling shows that this is because longer variations spend more time in selectBest(), giveCredit(), progressiveWidening(), and other tree management routines. So, a few questions: 1) are your measurements also in the context of a UCT tree? 2) what slowdown do you observe as search progresses? Your answers will go a long way towards helping me to understand how a world-class engine performs. I appreciate that you help the community in this way. TIA, Brian ___ 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] MoGo policy: capture stones anywhere?
I maintain a list of strings with exactly one liberty. If I disable the code to track one liberty groups and generate capture moves the speed goes up from 17.7 K playouts/s to 18.1K playouts/s, so it's a small difference, probably not statistically significant. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Peter Drake Sent: Monday, August 31, 2009 9:56 PM To: Computer Go Subject: [computer-go] MoGo policy: capture stones anywhere? MoGo's playout policy (at one time) is given in section 3.2 of Gelly et al's paper, Modification of UCT with Patterns in Monte-Carlo Go: We describe briefly how the improved random mode generates moves. It first verifies whether the last played move is an Atari; if yes, and if the stones under Atari can be saved (in the sense that it can be saved by capturing stones or increasing liberties), it chooses one saving move randomly; otherwise it looks for interesting moves in the 8 positions around the last played move and plays one randomly if there is any; otherwise it looks for the moves capturing stones on the Go board, plays one if there is any. At last, if still no move is found, it plays one move randomly on the Go board. We've implemented much of this, which has made Orego considerably stronger. The problem is with this part: otherwise it looks for the moves capturing stones on the Go board Does this really mean traversing the entire board looking for captures? Doing so seems to create a catastrophic speed hit. Peter Drake http://www.lclark.edu/~drake/ ___ 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/
