Thanks, threads were set to 8 because of memory problems. My machines have 16GB and 15GB. I hoped the playing strenght would not differ too much, as I thought I fixed the number of playouts. So it might be slower of cause...
At the moment I do not have disagrees about outcomes, but I will keep it in mind in case of problems. I think all games are resigned... From the pachi README file coming with the version I use it should use large patterns, at least it does mention using it and is not mentioning that I have to turn it on :) Detlef Am Donnerstag, den 19.12.2013, 11:17 -0700 schrieb Martin Mueller: > Are my fuego parameters ok? > > opponent_settings2='uct_param_player ignore_clock 1 > > \nuct_param_player > > max_games '+str(playouts)+'\nuct_param_player resign_min_games 5000 > > \nuct_param_search number_threads 8\nuct_max_memory 8000000000 > > \nuct_param_player reuse_subtree 1' > > Hi Detlef, > looks OK generally. Some comments: > > > In my normal tests I set > uct_param_search number_threads 1 > instead of 8, then I run several test games in parallel with the — > threads option in gogui-twogtp. > > > The reason for single-threaded is that I want to separate “baseline” > strength comparison from parallel scaling performance. So I want to > keep the baseline as simple as possible. > > > Of course then you need to reduce the memory per player as well. I do > not know how much weaker the current Fuego is on 8 threads, as > compared to running single-threaded 8 times longer. It totally depends > on your hardware too. You can easily measure the raw parallel speedup > by using the tool fuego/tools/misc/fuego-speed-test.pl > E.g. 6.5 for 8 threads is not bad in terms of nodes/sec. speedup. But > strength speedup is less because the parallel algorithm is less > informed than the sequential baseline. > > > Talking of memory, using 8000000000 on a 8GB machine may be a bit too > much, depending on what else runs on your computer and how large the > memory footprint of the rest of Fuego is. You don’t want it to start > swapping. We have used something like 7.3GB for the tree which is > probably conservative. There is a patch coming up which will reduce > the memory footprint of Greenpeep style patterns a bit. > > > Then of course, once in a while we need to check parallel scaling as > well, as Markus did for the paper we wrote a long time ago. > > > The other thing I do is I set > go_rules cgos > This keeps things simpler for scoring in the end. Other rules support > in Fuego is a bit flaky. (I am not sure what is the default if you > specify nothing) > And I still use GnuGo as a referee, there are always some games where > the programs disagree in the end. Those end up in the “future work” > bucket :) > > > Martin > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
