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 < [email protected]> wrote: > Don Dailey wrote: > >> On Tue, May 12, 2009 at 12:16 PM, Michael Williams < >> [email protected] <mailto:[email protected]>> 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 > [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/
