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