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

[Michael Petch]

On 10/09/09 3:07 PM, "Philippe Michel" <address@hidden> wrote:

> You wrote about using more threads than cores before. It would look
> plausible if they could be blocked on I/Os for instance, but I don't see
> how it would help here, with all of then CPU-bound.

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).

Often what I observe is that moves are allocated to available thread (Easy
to see with top) and as moves get finished threads become increasingly idle
until it is the last major move to complete that sits there. With more
threads more of the moves start at earlier time interval so I see less
thread idle time near the end. This is especially true with 4ply analysis.
4ply/4ply usually with 700-800 moves generally takes a few hours, but I
notice this more under those conditions. Probably because some moves can
take 4 mins to analyze by themselves.

As for Gnubg locking I have never seen this behaviour, but I wonder if this
has to do with the windows release (Any heavy work I don;t do on windows)
where Windows itself is being starved of CPU time and things appear to
freeze (Easily reproducible if you set the priority to the highest setting
and set threads=cores). One thing to note, and this is for people using
4ply, often you'll see Gnubg become unresponsive and the graphics don't
update. If you wait long enough it usually comes back, sometimes on the oder
of minutes.

There is no hard and fast rule that it should be double or triple (But more
threads than cores does make a difference for me.. Probably on the order of
5-10%). There will be a point where there will be diminishing returns. The
same holds true for the cache. If you set the cache to its highest setting
it may often perform much worse than if it had been set in the middle (168mb
vs 21mb).