Re: [Bug-gnubg] Removal of non-threaded code

[Christian Anthon]

I have timed some simple evaluations of the opening positions using various compile settings. The following times is reported for each of the compile settings.

A. 3x 4ply evaluation (clearing the cache in between with a command that is not in the present code)
B. 3x clearing the cache without any evaluation
C 1000x 2ply evaluation (clearing the cache in between)
D 1000x clearing the cache

The lost time is from locking and unlocking the cache, I believe.

threaded
146.307531
0.011090
104.297596
3.803742

non-threaded
138.310104
0.010516
92.876412
3.614214

threaded-sigmoidSSE
139.664481
0.011588
95.686871
3.824007

non-threaded-sigmoidSSE
131.947215
0.010806
87.237141
3.605156

from timeit import *

gnubg.command("set gnubgid  4HPwATDgc/ABMA:cAkNAAAAAAAA")

gnubg.command("set evaluation cube evaluation plies 4")
t = Timer('gnubg.command("clear cache"); gnubg.command("eval")', 'import gnubg')
print "%f" % t.timeit(3)

t = Timer('gnubg.command("clear cache")', 'import gnubg')
print "%f" % t.timeit(3)

gnubg.command("set evaluation cube evaluation plies 2")
t = Timer('gnubg.command("clear cache"); gnubg.command("eval")', 'import gnubg')
print "%f" % t.timeit(1000)

t = Timer('gnubg.command("clear cache")', 'import gnubg')
print "%f" % t.timeit(1000)

On Wed, Apr 29, 2009 at 2:38 PM, Massimiliano Maini <address@hidden> wrote:

Jonathan Kinsey <address@hidden> wrote on 29/04/2009 12:54:26:

> Massimiliano Maini wrote:
> >
> > Christian Anthon wrote on 29/04/2009 10:23:59:
> >
> >> On Wed, Apr 29, 2009 at 10:04 AM, Massimiliano Maini
> >> address@hidden> wrote:
> >>
> >> bug-gnubg-bounces+massimiliano.maini=amadeus.com@gnu.org wrote on
> >> 28/04/2009 22:01:23:
> >>
> >> MaX build with single thread : ~32400 eval/s
> >> MaX build with MT code, 1 thread : ~24800 eval/s
> >> MaX build with MT code, 2 threads : ~34600 eval/s
> >>
> >> However, a quick rollout (648 trials, expert, full, 2 top moves of
> > postion
> >> t60BYCButycAAA:cAnnAWAASAAA) has shown the following:
> >>
> >> MaX build with single thread : 2m04s
> >> MaX build with MT code, 1 thread : 2m04s
> >> MaX build with MT code, 2 threads : 1m48s
> >>
> >> I'm much more worried about the last two numbers here. MT code
> >> should give close to twice the speed, or we are doing something wrong.
> >
> > Here at office the PC is single core, don't know if this explains the
> > "poor" result. I'll check at home (dual core).
>
> You did say the pc was "1 core, 2 threads", does this mean it's a
> hyper-threaded
> machine? That would match a small increase for 2 threads,

Yes, 1 core with hyper-thread. I wasn't really surprised by the small increase.

> note also that the 1
> thread test will be using 2 threads (one for the gui and one for the
> evaluations
> - the gui thread will only be redrawing the screen).
 

I run the calibrate on the command line version and the rollout in the gui
one. Not sure it's a big deal however ... just a progress bar and a few numbers
updated from time to time ...

> The best test would be on a simple single core/processor machine, these are
> getting quite rare, all the pcs I see are multi-core now.

MaX.