Re: FW: [Bug-gnubg] Simple multi-threading... Cache

[Jim Segrave]

On Tue 23 Jan 2007 (12:46 +0000), Jonathan Kinsey wrote:
> Jonathan Kinsey wrote:
> > Jim Segrave wrote:
> >> Yes - cache entries are indexed by position and evaluation (although,
> >> as I recall, it's evaluation type and no. of plies, so if you were
> >> doing 2-ply evaluations with different move filters for different
> >> players, I think it would not see the difference in evaluations.
> >>
> > 
> > I've had a look at where multiple evaluations differ (with the same
> > cache lookup values - basically the same position/eval settings).  It
> > turns out it's to do with the NNevalAction/State thing, one time it
> > calculates Evaluate128() and the other EvaluateFromBase128() - they
> > produce different answers.
> > 
> > This is single threaded - still not sure exactly how the state things
> > work, maybe I've broken that logic!...
> 
> Just checked with the pre-multi threaded source and I get the same
> issue.  So might be a problem (or a "feature") with the FromBase
> evaluation shortcut.

Just loking at neuralnetsse.c, and not burdening myself with acutally
understanding the neural net code itself, it looks like calls to
NeuralNetEvaluate128() take a flag with values NNEVAL_NONE,
NNEVAL_SAVE and NNEVAL_FROMBASE. 

calling with NNEVAL_NONE doesn't copy arInput[] to the neural net
savedBase, but simply calls Eval128().

Calling with NNEVAL_SAVE does copy arInput[] to the neuralnet
savedBase, then calls Evaluate128()

calling with NNEVAL_FROMBASE assumes that there is a savedBase for
this neural net and that it should be restored to arOutput, then used
to tweak the values of arInput before calling EvaluateFromBase128().

My first thought would be - does the multithreaded code have separate
copies of the savedBase struct for each of the neural nets? If not,
there will be unpleasant interactions.

-- 
Jim Segrave           address@hidden