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

[Michael Petch]

On 10/09/09 3:58 PM, "Michael Petch" <address@hidden> wrote:

> 
> Probably because when I am doing any significant measurements its usually on
> simultaneous rollouts. My CPU's stay pegged for long durations of a rollout
> (And this is under Linux). As for standard analysis far less so, but when
> games are shorter the more moves that can be analyzed at once the less
> likely the CPU is idle on the last two thirds of the game (excluding the
> beearoff since it comes from the database and goes faster) you will have
> threads fighting for contention at the beginning but this dies down as
> threads run out of work near the middle).

I should point out that I haven't done any empirical studies with releases
threads and cache in nearly 18 months. Given the things that have changed
(Caching bugs on 4 ply which I use heavily), I am unsure if things have
changed.

With that being said, I did a quick 2ply test (I don't usually time 2 ply
since it doesn't take long), but an interesting foot note is this (And this
is justa  2ply sample).

On a single 815move match, 2ply/2ply (NO pruning), Huge filter, Cache 21mb
on an 8 core system I saw these numbers, Priority -19:

8 thread, 10 trials : 28.05 mean, Std Dev of .12
12 thread, 10 trials : 30.34 mean, Std Dev of .31
16 thread, 10 trials : 32.30 mean, Std Dev of .72

Clearly for at least simple analysis on 2 ply thread count exceeding cores
drops off immediately. I'll run some rollout tests, and 4ply and see what
the numbers show. I'll probably redo the cache size tests as well. As Ingo
has learned (which correlates to what I have observed) the largest cache
sizes can degrade performance - and we likely might want to change the GUI
slide bar for cache based on new data.

Coincidentally, I had a discussion with Neil Kaz about cache size last night
and suggested he use 21mb.

I'll get back to the list with some other test results on the weekend.