bug-gnubg
[Top][All Lists]
Advanced

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

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.





reply via email to

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