I've checked in a small change that should overcome this scaling issue, very
limited testing so could easily contain problems...
Jon
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.
>
> Jon
>
>
_________________________________________________________________
Use Hotmail to send and receive mail from your different email accounts.
http://clk.atdmt.com/UKM/go/167688463/direct/01/
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
