From be852ed19f9d8d2d7c836af0639936cb1debc42f Mon Sep 17 00:00:00 2001 From: r6144 Date: Thu, 14 Jul 2011 12:28:28 +0800 Subject: [PATCH] Yet more notes on memory management. --- NOTES | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NOTES b/NOTES index 2f94e9d..28b2e96 100644 --- a/NOTES +++ b/NOTES @@ -6,9 +6,9 @@ TODO: When the dynkomi is adjusted, the existing values in the tree are not recomputed, so if large changes in dynkomi is present during one move, the average values and scores will be inaccurate, and more importantly, nodes expanded early will have biased values and thus be explored too (in)frequently. Resign decisions and some timing decisions will be affected as well, although since the statistics used for dynkomi adjustment itself are reset in komi_by_value(), dynkomi adjustment is not affected. Perhaps we should include a larger linear section (5 points should probably be reasonable) in scale_value(), and avoids adjusting the dynkomi during a move (as opposed to adjustments between moves) unless the average is near the boundary of this linear section, and a correction may be introduced even in this case. However, other thresholds depending on the average value, such as the resign threshold, should be adjusted accordingly. Alternatively, we can adjust up or down the value according to the current dynkomi. -Memory use could be optimized. The depth and playout count thresholds when pruning should be adjusted more robustly according to the maximum size of the temporary tree; currently it is possible that the maximum temp tree size gets exceeded before all nodes within the playout count threshold are included (take a look at the pruning statistics; the unit is bytes and each node is currently 88 bytes on a 64-bit system, and "temp tree overflow" will be reported). Finally, it seems to be inefficient to expand all the (often 300+) children of a node at once whenever its playout count reaches expand_p (and memory is available). Of course, allowing pruning during a move may well be helpful with limited memory and long thinking times, but thread synchronization must be done carefully, and the aforementioned robustness issues of the pruning process would become more important. +Memory use could be optimized. The depth and playout count thresholds when pruning should be adjusted more robustly according to the maximum size of the temporary tree; currently it is possible that the maximum temp tree size gets exceeded before all nodes within the playout count threshold are included (take a look at the pruning statistics; the unit is bytes and each node is currently 88 bytes on a 64-bit system, and "temp tree overflow" will be reported). Finally, it seems to be inefficient to expand all the (often 300+) children of a node at once whenever its playout count reaches expand_p (and memory is available); due to the relatively high first-play urgency when explore_p is high, a few more playouts on the parent node will visit a similar number of these child nodes, but many of the children are still untouched, and eeven the touched ones only need a small amount of information. Of course, allowing pruning during a move may well be helpful with limited memory and long thinking times, but thread synchronization must be done carefully, and the aforementioned robustness issues of the pruning process would become more important. -Make the program pass properly at endgame. +Currently, pruning is necessary during tree_promote_node() under fast_alloc, because we only have a limited amount of space to copy the surviving nodes into. This wastes a bit of time in copying (although without fast_alloc, freeing the numerous dead nodes individually will be even slower, and in any case marking the surviving nodes will take almost as many cache misses as copying), and while the pruned nodes are expanded again. To solve this problem, we can add a version number to each node which is incremented only for surviving ones, and in this way it will be easier to find free nodes; however, threading issues remain to be considered. Fix the "cannot promote move node" problem when run under gogui-twogtp. -- 2.11.4.GIT