Re: [Bug-gnubg] Question about higher plies

From:

Joseph Heled

Subject:

Re: [Bug-gnubg] Question about higher plies

Date:

Tue, 27 Jul 2004 19:23:57 +1200

User-agent:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

First, don't forget that the real expensive call is NeuralNetEvaluate (and
friends). Would be nice to see some profiling info, but CalculateHalfInputs
would be a distant second, I guess. The real time saver is the usage of my small
nets. Unfortunately, it never went into the mainline since my eval.c and GNUGB's
have diverged too much, so it is not trivial.

-Joseph
Jim Segrave wrote:

On Mon 26 Jul 2004 (19:23 +0000), Joern Thyssen wrote:

On Mon, Jul 26, 2004 at 10:51:21PM +0200, Jim Segrave wrote

I think the classification is probably cheap in CPU time compared to
the evaluation. What might be profitable is trying to save some of the
information from the classification for setting up the inputs to the
neural net. since I'd guess there's a lot of similar work being done.

Yes, I've thought about this as well.

CalculateHalfInputs is the expensive function, and the function is
unfortunately two-sided, so it's not possible to do one-sided caching

which would be very efficient.

I'm fairly sure some bit maps of
occupied points (at least one piece)

made points (2 or more pieces)
points with spares (3 or more pieces)
and bit maps of possible moves would lead to significant execution
time savings in this routine. One of these days, if I ever get enough
time, I want to look at recoding this portions, since gprof suggests
that it does consume a fair bit of time in setting up the neural net
inputs. For example, suppose you build bit maps at the start of the
routine for each player, in each direction:
occupied[player][point] = bits 23..0 set to indicate a piece on 24..1
made[player][point] = same for points made
spares[player][point] = same if made and has a spare
and the reverse mapping
occupied_r[player][point] = bits 0..23 set to indicate a piece on 24..1
made_r[player][point] = same for points made
spares_r[player][point] = same if made and has a spare
Then you can convert a dice roll into a set of bit maps
representingn where a piece could move to:
5 = 1000010 for one piece moving 2 then 5
= 1010000 5 then 2
= 10000 just moving 5
= 10 just moving 2
I'm guessing (without having coded any of this), that shifts and
bitwise operators would beat the multiple iterations over the board
array that's currently being done to determine what moves are legal. I
think there are some other tricks with bit masking which would allow
ansering the questions of number of men back, presence of anchors, etc.