Here are the results of fuego svn version 13x13 board, against pachi with pachi having 4*playouts Totally 672 games...
I will give the 19x19 board a chance now:) Detlef Am Donnerstag, den 19.12.2013, 19:52 +0100 schrieb Detlef Schmicker: > 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 > > Computer-go@dvandva.org > > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go > > > _______________________________________________ > Computer-go mailing list > Computer-go@dvandva.org > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
playouts_fuegosvn.pdf
Description: Adobe PDF document
_______________________________________________ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
