|Subject:||Re: [Bug-gnubg] How many threads can gnubg (reliably) handle?|
|Date:||Fri, 11 Sep 2009 15:23:43 +0000|
I've checked in a small change that should overcome this scaling issue, very|
limited testing so could easily contain problems...
Jonathan Kinsey wrote:
> Philippe Michel wrote:
>> On the other hand, analysis doesn't seem to scale well above 8 threads.
>> It looks like moves are analysed one by one and after the opening and
>> early middle game, even with a large move filter, some, then most of the
>> threads are starved. 8 threads was about 7 times faster than 1, but 16
>> threads was merely 9 times faster.
> This is almost definitely caused by the fact that I wrote the code to analyse
> each game separately, i.e. all the moves in one game are dished out and then
> waited for before the next game is analysed. This means that towards to end of
> each game lots of threads will wait for the last moves to finish.
> The answer would be to split out all the moves of the entire match in one go,
> shouldn't be too hard as long as it doesn't break anything. This would be
> worthwhile as it would speed up things slightly even for small numbers of cores.
Add other email accounts to Hotmail in 3 easy steps. Find out how.
|[Prev in Thread]||Current Thread||[Next in Thread]|