Hi Jon, I assume you tested 2 ply. 4ply will continue to get faster with increased cache sizes. At least until I ran out of my 2GB of memory. But why do we need this large a cache when we only need to store 21+21^2+21^3+21^4 = 204204 positions to do a full 4ply, which is < 2^17 entries taking in to account that the current cache store two positions per entry. It doesn't seem very rational.
Christian. On Thu, Sep 3, 2009 at 12:27 PM, Jonathan Kinsey<[email protected]> wrote: > As the cache gets larger it riches a natural plateau, in my initial tests > this > was at the current gui limit (4gb entries), I was looking at Ingo's results > just > yesterday and there was little (or no) improvement above 2^15 entries. The > settings and position types will be a factor. > > It's quite easy to try out, just use the "set cache" command, you need to > enter > the number of entries in powers of 2 though, so the current maximum (2^22) > would be: > set cache 4194304 > just times this by 2 to increase the cache (obviously this doubles the > memory > usage as well). > > I'd be interested in your results as it might be worth changing the > minimum/maximum and default settings displayed in the gui. > > Jon > > Michael Depreli wrote: >>>From my tests the extra speed from using max cache although not huge >> was worthwhile. >> Given like you say>2gb is the norm (I have 4gb) would it be worth >> having an even larger cache available in gnubg? >> >> >> ------------------------------------------------------------------------ >> From: [email protected] >> To: [email protected] >> CC: [email protected] >> Subject: Re: [Bug-gnubg] Cache question >> Date: Thu, 3 Sep 2009 09:37:15 +0000 >> >> The only reason is if the memory usage has any impact for you (running >> several >> copies at the same time for example), it's getting a lot less likely >> that this >> is the case with>2gb becoming the norm on new pcs. >> >> You might find that there is little difference in speed between the >> maximum and >> one-down setting (and this would save you 80mb of memory). >> >> Jon >> >> Michael Depreli wrote: >>> I ran some brief tests using rollouts with different cache settings and >>> larger cache produced faster results (not linear). >>> Are there any known issues (bugs) running gnubg with cache set to max >>> for evals and rollouts for plies up to 2? >>> If not are there any reasons to not set cache to max? >>> >>> Michael >>> >>> >>> ------------------------------------------------------------------------ >>> View your other email accounts from your Hotmail inbox. Add them now. >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Bug-gnubg mailing list >>> [email protected] >>> http://lists.gnu.org/mailman/listinfo/bug-gnubg >> >> >> >> >> ------------------------------------------------------------------------ >> Add other email accounts to Hotmail in 3 easy steps. Find out how. >> >> ------------------------------------------------------------------------ >> New! Receive and respond to mail from other email accounts from within >> Hotmail Find out how. > > > > > ________________________________ > View your other email accounts from your Hotmail inbox. Add them now. > _______________________________________________ > Bug-gnubg mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/bug-gnubg > > _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
