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 <
[email protected]> wrote:
>
>
> Jonathan Kinsey <[email protected]> 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
> > >> [email protected]> wrote:
> > >>
> > >> [email protected] 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.
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
