[Top][All Lists]
[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: |
Wed, 9 Sep 2009 21:39:19 +0200 (CEST) |
User-agent: |
Alpine 2.00 (BSF 1167 2008-08-23) |
On Tue, 8 Sep 2009, Michael Petch wrote:
I use 8 cores on Linux with no real issues.
I have run a few 4-ply match analyses (no rollout yet) on a 16 cores
machine (CentOS 5, x86_64) with no obvious problems.
Time will tell on how well Gnubg scales on a large number of processors.
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.
I guess this won't be a problem for rollouts.
I tried large cache sizes as well and saw no problems up to 1G cache
entries. Trying to set cache size to 2G fails silently. "set cache" uses
ParseNumber() that cannot handle it and there may be other int variable
involved as well. "show cache" from the CLI doesn't seem to work either.
For these match analyses, cache size above 256M didn't improve speed
anyway.