bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] speed of evaluation


From: Jim Segrave
Subject: Re: [Bug-gnubg] speed of evaluation
Date: Fri, 21 Nov 2003 02:02:09 +0100
User-agent: Mutt/1.4.1i

On Thu 20 Nov 2003 (22:52 +0100), Achim Mueller wrote:
> * Jim Segrave wrote on 20 Nov 2003:
> 
> > On Thu 20 Nov 2003 (09:18 +0100), Achim Mueller wrote:
> > > hi folks,
> > > 
> > > how does it come that gnubg's evaluation of a move/cube decision
> > > lasts appr. 10 or 20 times longer in the gui than in cli? I checked
> > > this on different linux distributions, but not on MS Windows.
> > 
> > I don't see a 10 to 20 times difference - analysing a match takes 10m
> > 30 seconds in the gui version vs. 7m 25 when run with the -t command
> > (FreeBSD, 2.3Mhz machine, match of 231 moves, analysed at
> > Supremo). I've run a profiler in both modes and will have a look.
> 
> It is at least 10/20 times when considering moves ... I didn't 

It's harder to measure this, unless you set the player eval to
something silly.

> > I thought it might be the Python thread, but ./configure
> > --without-python and a make clean; make made no difference. The
> > profiler output may give a clue.
> 
> I still think it's something concerning the graphic/gui itself.

There's certainly something odd going on. I have a profiler output of
gnubg analysing a game, once run under the gui, the second time from
the CLI. Same game, same .gnubgautorc. The GUI version is taking 40%
longer to do the exact same job.

The profiler output from running an analysis is interesting - both
versions took the same amount of CPU time (within the limits of the
test where I started the analysis by hand). In fact, the GUI version
executed slightly faster, althogh this was probably just variations in
how I started the analysis:

GUI:
each sample hit covers 4 byte(s) for 0.00% of 410.95 seconds

Text mode:
each sample hit covers 4 byte(s) for 0.00% of 414.56 seconds

But the wall clock time was much higher for the GUI, which suggests
that it was not runnable for a larger portion of the time, presumably
waiting n a syscall, perhaps a deliberate sleep or similar.

There's something wrong here, I'm not sure what.

> PS. Jim, if you have the time I can give you an account at my pc in
> Frankfurt (but I need your ssh public key then), will mirror my
> gnubg directory and you compile and debug here. GUI will be awfully
> slow while tunneled through ssh, but at least you may get the
> debugging output.

Thanks, but I have both Linux and FreeBSD machines available for
testing. I've run X apps with the X server tunneled through ssh before
and it's something I like to avoid unless I am forced to by something
like firewall issues. My DSL connection isn't fast enough to make this
anything but a desaraton measure.




> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnubg


-- 
Jim Segrave           address@hidden





reply via email to

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