The problem with making it dynamic with respect to how much memory is available is that this does not play well with other software. Since modern operating systems are designed for multiple processes, you don't want the amount allocated to be a function of which program got loaded first.
Can you imagine testing 2 GO programs designed this way? The first program which happened to get loaded would suck up all the memory. Or even if it grabbed half the memory, the other program might also grab half of what was left. This would give an unfair advantage to one program over the other based solely on which got loaded first. What makes the most sense is to have a modest default size, but make the amount of memory used user configurable. If you take the point of view that the end user isn't smart enough to make those decisions, you might set it to be some modest fraction of the size of the TOTAL memory installed in the computer, but I think this is still dicey. With these caveats explained to the end user, you could have a special mode they have to activate, which causes the program to allocate as much as possible with the understanding that this mode is for dedicated play - it assumes the computer is not being used for anything else. - Don 2009/7/6 terry mcintyre <[email protected]> > Considering that memory keeps getting cheaper, would it make sense to > dynamically choose how much space to use? > > Nowadays most new computer purchasers start with 2 GB, and go up from > there. > > Terry McIntyre <[email protected]> > > “We hang the petty thieves and appoint the great ones to public office.” -- > Aesop > > ------------------------------ > *From:* David Fotland <[email protected]> > *To:* computer-go <[email protected]> > *Sent:* Sunday, July 5, 2009 9:05:45 PM > *Subject:* RE: [computer-go] Hash tables > > The hash table contains a linked list of nodes with the same hash index. > > Your description is pretty close, but I don't remember the exact details. > Yes, I keep around some nodes for while, but eventually old nodes go into > the past and can be recovered. > > I actually have fewer total nodes than you do. The commercial version > allocates 30K nodes per CPU core. The version in the world championship > had > much more, but the commercial version can't be that greedy for memory. > > David > > > > > > I give up when there are no nodes that area available to be > > > overwritten. > > > > I'm still a little confused. > > > > First, does the hash table contains pointers into a node pool, or do > > you use the node pool as the hash table? > > > > Second, how and when do you determine which nodes (if any) are > > available for overwriting, without doing some sort of traversal? > > > > Is the following a correct summary of what you do when it's time to > > create a new node? > > > > Go to the one node that would be used for this Zobrist hash. If the > > same hash is stored there, use the existing node. If not, either > > overwrite this node (if this node is available for overwriting) or not > > create a new node (otherwise). > > > > Also, what exactly is the criterion for overwriting? You said "nodes > > that have few visits or are old". Is this just (visits < > > visitThreshold) || (depthFromBeginningOfGame < currentGameTurn)? > > Doesn't depthFromBeginningOfGame cause you to keep around nodes that > > are outside the still-relevant branch of the tree (i.e., the branch > > descending from the current root), almost all of which are irrelevant? > > > > > If the search is long enough, there are no nodes that can be > > > recovered, and the > > > UCT tree stops growing. I keep searching when there are no reusable > > > nodes. > > > > > > ...because this improves the quality of information in the nodes you > > were able to create. That makes sense. > > > > Thanks, > > > > Peter Drake > > http://www.lclark.edu/~drake/ <http://www.lclark.edu/%7Edrake/> > > > > _______________________________________________ > > computer-go mailing list > > [email protected] > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
