Are we approaching a point where it would be practical to precompute the opening tree to some depth, cache the results on SSD, and incrementally improve that knowledge based upon subsequent games?
Terry McIntyre <terrymcint...@yahoo.com> On general principles, when we are looking for a solution of a social problem, we must expect to reach conclusions quite opposed to the usual opinions on the subject; otherwise it would be no problem. We must expect to have to attack, not what is commonly regarded as objectionable, but what is commonly regarded as entirely proper and normal. – John Beverley Robinson, 1897 ________________________________ From: Michael Williams <michaelwilliam...@gmail.com> To: computer-go <computer-go@computer-go.org> Sent: Tuesday, May 12, 2009 10:18:28 AM Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS In my system, I can retrieve the children of any node at a rate of about 100k nodes/sec. And I can save nodes at a rate of over 1M nodes/sec (this is much faster because in my implementation, the operation is sequential on disk). Those numbers are from 6x6 testing. Don Dailey wrote: > This is probably a good solution. I don't believe the memory has to be very > fast at all because even with light playouts you are doing a LOT of > computation between memory accesses. > All of this must be tested of course. In fact I was considering if disk > memory could not be utilized as a kind of cache. The secret would be to > store complete trees in disk memory, trees that are not likely to be utilized > but can be utilized in a pinch. The tree store and retrieved must outweigh > by a large factor the amount of time spent creating the tree in the first > place in order for this to pay off. > My guess is that this is impractical, but it's fun to think about how it > might be done. I'm not sure how to do it without having a caching nightmare. > > > - Don > > > > On Tue, May 12, 2009 at 12:41 PM, Michael Williams > <michaelwilliam...@gmail.com <mailto:michaelwilliam...@gmail.com>> wrote: > > Don Dailey wrote: > > On Tue, May 12, 2009 at 12:16 PM, Michael Williams > <michaelwilliam...@gmail.com > <mailto:michaelwilliam...@gmail.com> > <mailto:michaelwilliam...@gmail.com > <mailto:michaelwilliam...@gmail.com>>> wrote: > > I have a trick ;) > > I am currently creating MCTS trees of over a billion nodes on > my 4GB > machine. > > > Ok, I'll bite. What is your solution? > > > I use an SSD. There are many details, of course. But it's still in > the works and I'm still making lots of changes and adjustments. I > seem to be able to "solve" (there are lots of definitions) 6x6 Go in > that when I use a komi of 3.5, it is unable to find a winning line > for white and when I use 4.5, it is unable to find a winning line > for black. > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org <mailto:computer-go@computer-go.org> > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
