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 speed.
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. Christian. On Thu, Apr 21, 2011 at 4:31 PM, Ian Shaw <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-gnubg > > _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
