Re: [Bug-gnubg] How many threads can gnubg (reliably) handle?

[Michael Petch]

On 11/09/09 3:06 PM, "Philippe Michel" <address@hidden> 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)