[Top][All Lists]
[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
- [Bug-gnubg] speed of evaluation, Achim Mueller, 2003/11/20
- Message not available
- Re: [Bug-gnubg] speed of evaluation, Jim Segrave, 2003/11/20
- Re: [Bug-gnubg] speed of evaluation, Achim Mueller, 2003/11/20
- RE: [Bug-gnubg] speed of evaluation, Ned Cross, 2003/11/20
- Re: [Bug-gnubg] speed of evaluation, Jim Segrave, 2003/11/21
- Re: [Bug-gnubg] speed of evaluation, Jon Kinsey, 2003/11/21
- RE: [Bug-gnubg] speed of evaluation, Ned Cross, 2003/11/21
Re: [Bug-gnubg] speed of evaluation, Achim Mueller, 2003/11/21