[Computer-go] Fuego in Kanazawa and UEC Cup

Michael Williams michaelwilliams75 at gmail.com
Mon Nov 29 21:48:54 PST 2010


Since you brought up virtual losses, I wanted to point-out something
that occurred to me recently:  you don't have to use just one virtual
loss.  You can add N visits to a node when you visit it and then
remove N-1 visits when you update the node with the playout result.
The larger N is, the less different threads will step on each other.
Of course increasing N also means an increased likelyhood of exploring
irrelevant paths.



On Mon, Nov 29, 2010 at 4:33 PM, Richard B Segal <rsegal at us.ibm.com> wrote:
> Hi Everyone,
>
> Aja's description of Fuego in the UEC cup is pretty accurate. The main
> changes to Fuego for both events were to improve scaling on the 112 core
> system. The move generation algorithm was mostly identical to the SVN source
> for both Kanazawa and the first day of the UEC cup.
>
> We did make a possibly significant change for the last two matches of the
> UEC cup. Once in Kanazawa and once on the first day of the UEC cup Fuego
> lost by attacking with a ladder that would ultimately fail. Fuego has a root
> filter that prevents extending a group that will be captured in a ladder,
> but it does not filter failed attacks. I modified Fuego's root filter for
> the last two matches to remove failed attacks as well. I also modified the
> code to apply the root filter (minus its safety check) at all levels of the
> search. While the new code did not show any improvement in self play, it did
> improve its handling of the position that led to the failed ladder attack in
> the UEC match against Erica.
>
> The other change between Kanazawa and the UEC cup was regarding some
> experimental code to improve exploration. The experimental code appears to
> be effective for 9x9 play, but its value for 19x19 play was questionable. I
> had weak experimental data (50 games) in Kanazawa suggesting it may be
> useful so I enabled it for 19x19 as well. A similar weak experiment just
> before the UEC cup showed a 50 ELO loss so it was disabled for the UEC cup.
>
> Probably the most important change for running on the 56 core system was
> switching from floats to doubles to score move evaluations. After about one
> million trials, the limited precision of floats becomes a bottleneck to
> improved play. I made a few small modifications to the virtual loss code to
> ensure that virtual losses were added as early as possible, and removed as
> late as possible to maximize their effect. I also separated out the counting
> of virtual losses from the UCT statistics to reduce the chances of
> simultaneous updates as simultaneous updates can introduce counting errors.
>
> The final addition was a new parallel tree copy algorithm that was needed
> due to the large 200Gb RAM available on the 56 core system. When Fuego runs
> out of memory, it copies its current tree to a new tree while removing nodes
> with a small number of trials. The single threaded copy algorithm took up to
> 20 seconds on a 200Gb tree. The parallel tree copy algorithm reduces the
> same copy to about 4 seconds.
>
> We plan to eventually move most if not all of these updates into the public
> Fuego source tree. For completeness, the configuration script used for UEC
> was as follows:
>
> go_rules japanese
> time_settings 1800 0 0
> komi 6.5
>
> uct_max_memory 175000000000
>
> uct_param_player ponder 1
> uct_param_player reuse_subtree 1
>
> uct_param_search lock_free 1
> uct_param_search number_threads 112
> uct_param_search number_playouts 2
>
> # Enable new parallel tree copy
> uct_param_search max_copy_threads 8
>
> # New features added on second day of UEC cup
> uct_param_globalsearch use_filter 1
> uct_param_rootfilter check_offensive_ladders 1
>
> - Rich
>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>



More information about the Computer-go mailing list