bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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 ~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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]