|
From: | Philippe Michel |
Subject: | Re: [Bug-gnubg] How many threads can gnubg (reliably) handle? |
Date: | Fri, 11 Sep 2009 23:06:49 +0200 (CEST) |
User-agent: | Alpine 2.00 (BSF 1167 2008-08-23) |
On Thu, 10 Sep 2009, Michael Petch wrote:
On 10/09/09 4:33 PM, "Ingo Macherius" <address@hidden> wrote:My benchmarks with 4 cores showed that the cache brings about 10% improvement
And got this results : 8 thread, 0mb cache, 10 trials : 44.83 (seconds) mean, Std Dev of .18 8 thread, 21mb cache, 10 trials : 28.05 (seconds) mean, Std Dev of .12 Cache make a big difference in this case. A speed improvement of about 60%. I don't consider 60% insignificant and is well beyond 10% you were getting. I find that curious.
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 ~oklong 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
[Prev in Thread] | Current Thread | [Next in Thread] |