[Bug-gnubg] Two patch sets - one for Joseph Heled

[Jim Segrave]

Second try - I must stop typing gnubg.org, gnu does do a few other
things :-)

Attached are two sets of diffs for some changes to gnubg.

The first getmemultiple.diff.gz is of interest to everyone. I ran a
profiler on gnubg last week to see what it was doing while analysing a
match of 9 games, 376 moves. I found, according to gprof that it
called getME no less than 2 thousand million times (2 ** 9). getME()
itself is a fast enough routine, but looking at the code, the biggest
caller is GetPoints(), which calls it repeatedly to get the match
equity for win, win gammon, win backgammon, win doubled, ... I think
something like 14 calls/invocation.

I wrote a verson getMEMultiple, which gets all these values in one
call into an array. After some work checking that it appears to give
the same results (by doing a compare with the saved sgf files of the
changed code and the original, as well as running a test version with
asserts everywhere to look for differences, I think it's OK.

The result is startling - gnubg runs analysis and rollouts (world
class settings) about 150% faster - the analysis of the match I used
dropped from:
real    31m50.359s
user    31m23.026s
sys     0m0.579s

to
real    24m4.352s
user    22m39.503s
sys     0m0.493s

Running a rollout of a randomly chosen position on two copies at the
same time (top says they got equal CPU time) showed the same
properties - the modified version is completing almost exactly 1.5
times as many games as the unmodified. Makes gnubg have the reverse
trend from Snowie, as it's getting faster rather than slower.

I think there's a lot more performance to be gained, but it may be
harder work - the biggest time consumers are the setting up of the
neural net inputs and the evaluation of the net itself, neither of
which are trivial to change.

I am curious if changing EqualKeys() into a macro using memcmp (which
I think gcc will inline might not also be a big performance win - it's
called a similar *huge* number of times.

The second set of diffs is for Joseph - they include changes to allow
having pruning filters in an evalcontext, including text mode set,
show and save commands (pretty crude at the moment). No gui commands
exist yet.
The defaults are done as macros in eval.h
The old nooneplyprune and similar items are still in the evalcontext,
to make it easier to test code.
The set command is not so clever - 
set <context> evaluation movefilter i j k m f.f
  where i is the number of plies for which the filter is applicable (1..4)
        j is the level for the filter (0..i-1)
        k is the number of moves to accept regardless of search tolerance
        m is the number of extra moves to accept it they are within
          the tolerance
        f.f is the search tolerance

-- 
Jim Segrave           address@hidden

getmemultiple.diff.out.gz
Description: application/gunzip

heled.diff.out.gz
Description: application/gunzip