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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-gnubg > >
_______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
