gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] Timing data


From: Daniel Bump
Subject: [gnugo-devel] Timing data
Date: Fri, 22 Feb 2002 21:30:25 -0800

All regressions, current CVS:

alt and exp conn and exp influence: 29108 seconds
alt and exp conn                  : 27911 seconds

The penalty for the experimental influence seems to be about 4.2%

I have more specific timing information for strategy.tst alone. 
Inge pointed out that I should really use time to get the exact
CPU time but since comment came after these experiments
were already underway and I didn't want to switch my methodology
in the middle. Next time I'll do it Inge's way.

GNU Go 3.0.0:                            1049 seconds

>From http://mail.gnu.org/pipermail/gnugo-devel/2002-February/001407.html
(where strategy.tst is typo'd as semeai.tst),

CVS version of February 13, basically 3.1.25:

With alt. and exp. connections           2187 seconds
alt and exp conn. and exp. influence     2550 seconds
alt and exp conn. and exp. semeai        2249 seconds

Current CVS:

with alt. and exp. connections           1443 seconds
alt and exp conn. and exp. influence     1527 seconds

I'll report on semeai.tst later. There I'm not so concerned
with speed as with accuracy. There is a change I want to
try out related to the problem discussed in:

http://mail.gnu.org/pipermail/gnugo-devel/2002-February/001457.html

The problem described there suggests changes in both owl.c and
semeai.c but the changes in semeai.c are quite conservative and
sufficient to stop the behavior in that example. The question
is what effect they have on the overall regressions and I'd
like to test that next. This means that I must run the whole
regressions with experimental semeai (for which I have no
recent results) then repeat the experiment with my s

Perhaps we should make the experimental influence and
experimental semeai standard for 3.1.26. 

And perhaps we should think about releasing 3.2 soon.
The question is, if we put out a version which is 45%
slower than 3.0, is that acceptable?

I've seen some bad moves on NNGS recently. But the
experimental influence code hasn't played on NNGS. It
will be interesting to see how 3.1.26 does there.

Congratulations Arend on finding an excellent speedup.

Dan



reply via email to

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