On 11/09/09 3:06 PM, "Philippe Michel" <[email protected]> wrote: > > Surely, usefulness of a larger cache depends on the number of positions > evaluated. Maybe something like : > > 2 ply play seconds 10k positions cache almost useless > 2 ply analysis of match minutes 1M default size ok > 4 ply an./short rollout hours 100M max from GUI ~ok > long rollout days billions "set cache" from > CLI higher than GUI max useful if you have the RAM for it > > For case 3, maybe the maximum of the GUI slider could be increased by 2 or > 4. > > FWIW, in my (very limited) tests, cache size helped until 256M entries / > 11Gb : > > 4ply analysis of a match of about 350 moves, 16 threads on 16 cores > > cache entries real time CPU user time > 8M 21:52 193:04 > 16M 21:01 180:47 > 32M 19:26 167:33 > 64M 18:12 157:57 > 256M 16:53 150:06 > 512M 16:55 148:59 > 1G 17:13 149:03 > >
I was doing a limited test to see if there was something to persue here )And also trying to narrow down a bug that affects getting deterministic results). But I did an experiment last night. 4ply/4ply analysis. 60% speed increase. 11000 seconds vs 6265 (I ran the trial a few times to make sure the numbers were reproducible over a few hours and to verify the output was the same. Neil Kaz has taken an interest in this as well. He gave me some preliminary data with some rollouts he was doing. One thing he can confirm on his rollouts is that the larger cache size's don't hurt. Ingo's data (graph) shows a marked increase, and I wonder if that was swapping occuring (Although the physical memory in system should have been high enough) _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
