[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Fwd: Optimizing thread settings

From: Christian Anthon
Subject: Re: [Bug-gnubg] Fwd: Optimizing thread settings
Date: Thu, 21 Apr 2011 18:01:19 +0200

The evaluation speed tool always sucked, and it sucks twice with
threads. Do a rollout of some kind with a constant seed to test the

As for the technical part. Some Intel cpus have so-called
hyper-threading. For example some versions of the pentium 4 had it,
which mean that the OS saw two cpus, which together gave a 30%
increase in speed compared to running on one cpu. But that is not what
we talk about here. Threads in a programming sense is a fancy way to
split a program in to tasks that can run in parallel, with tools for
memory sharing,  memory protection, queuing, etc. If you split your
problem in to more tasks than you have cpus, you won't expect to gain
much, and often performance will be lowered. However, if you have a
lot of overhead from the program or other tasks running on the
computer, increasing the number of threads will steal time away from
the overhead tasks and therefore appear to increase performance. I
suspect that is what you observe here.


On Thu, Apr 21, 2011 at 4:31 PM, Ian Shaw <address@hidden> wrote:
> Hi,
> I'd like to understand how to optimize the "set threads n" setting for
> multi-processor computers.
> I've run the gnubg calibration speed test on a system with 2 x Xeon X3450
> 2.67 GHz CPUs. The CPU is listed as 4 cores, 8 threads.
> Threads   eval/sec
>  1          70k
>  2         150k
>  4         218k
>  8         266k (as recommended by the tooltip)
> 16         326k
> 24         342k
> 32         355k
> 40         362k
> 48         366k (the maximum configurable)
> For comparison, my P4 2 GHz single core desktop gives 25k eval/sec for any
> number of threads.
> My Core2 Duo T8100 2.1 GHz laptop gives:
> Threads   eval/sec
>  1          51k
>  2          98k (as recommended by the tooltip)
>  4          98k
> So, whereas the older PCs get no benefit from configuring more threads than
> physically available, the new processor can get improved performance by
> using more cores than physically present. If I'd just entered the
> recommended setting, I'd have chucked away a 37% performance benefit.
> Some questions:
> 1) How is it possible to get extra performance by using more threads than
> the computer has?
> 2) Is there a reason for the 48-thread limit? My performance gain was
> tailing off, but there might have been more available. I notice that 6-core,
> 12-thread processors are now available.
> 3) Should the tooltip be changed?
> Cheers,
> Ian Shaw
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-gnubg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]