Re: [Bug-gnubg] calculate_half_inputs - potential speed up

[Joseph Heled]

You may want to look again at gnubg-nn inputs.c . It does some pre computing  (into BoardCache) which is used by the various individual inputs. I think this takes care of most repeated computations. Also, gnubg-nn uses my modified  eggmove for generating moves which is far faster than gnubg main code.

I am really surprised no one has tried to merge back my changes into the main line, at least to see if they make a difference. By now the code may have diverged too much to make this an easy task.

-Joseph

On 30 July 2014 09:01, Philippe Michel <address@hidden> wrote:

On Tue, 29 Jul 2014, Ian Shaw wrote:

As I was pondering how gnubg evaluates positions, I realised that most of the time, the opponent's board layout is the same whatever move the player makes.  There are only likely to be a couple of changes, when chequers are hit. If the opponent fails to enter from the bar, the position could even repeat across moves.

The results of calculate_half_inputs for the opposing side could therefore be re-used for many positions, which could lead to a saving in processing if they are cached. Is this done at present? Or would checking for a cache entry itself take up too much time?

calculate_half_inputs is really :

CalculateHalfInputs(const unsigned int anBoard[25],
                    const unsigned int anBoardOpp[25],
                    float afInput[])

It depends on all the checkers, not just those from one side.

Now, many inputs depend on one side only, and if a few of them are expensive to compute it could be worthwhile to split it in two functions and somehow cache this part of the inputs.

I have attached a profile of this function in case someone wants to look at it.


Something that's probably worth to be cached is the position of each side's most backward checker. I think it is computed three times for each evaluation : in ClassifyPosition, then in CalculateHalfInputs, then again in SanityCheck. It could probably be found in the move generation and put in an additional "pseudo board point". Finding the number of checkers on the board or borne off is done more times than necessary as well.


Another wasteful thing in inputs computation is that all inputs but one (I_BACKBONE) are really integers that are normalized (by an expensive floating point division) before being multiplied by the first layer of weights.

If the neural net inputs were left as integers (that means replacing I_BACKBONE by an approximation and retraining, and applying the normalization to the weights), I think CalculateHalfInputs would be faster.

At a minimum, whe should just cast the inputs to floats and leave the division part to the loading of the first layer of weights.

If the imputs were integers, checking if they are 0, 1 or something else on integers instead of floats may help in the neural net routines as well.

_______________________________________________
Bug-gnubg mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-gnubg