Hello, In one of the latest version (21042009), there are moments where the cpu usage goes down, sometimes to ~50%. This wasn't happening before. With 'lost time' do you refer to this?
Joaquin 2009/4/29 Christian Anthon <[email protected]> > 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 > >
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
