[Computer-go] Fuego in Kanazawa and UEC Cup

Richard B Segal rsegal at us.ibm.com
Mon Nov 29 13:33:04 PST 2010



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20101129/17d3a0e6/attachment.html>


More information about the Computer-go mailing list