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

[Jonathan Kinsey]

Jim Segrave wrote:
> 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.

That's covered; each thread gets it's own savedBase (and NNEVAL state
thing).  This current problem is in the original code (i.e. single
threaded).

It seems that "save" and "from base" calls produce slightly different
numbers to a straight Eval128().  This might be just "noise" in the
floating point calculations, as it's in the 6th or so decimal place, for
example:

[0]     0.44384226
[1]     0.12797175
[2]     0.0040449966
[3]     0.15167633
[4]     0.0086114826

[0]     0.44384229
[1]     0.12797162
[2]     0.0040449873
[3]     0.15167636
[4]     0.0086114891

Maybe it's more significant in other example, as I wouldn't think this
would make a difference to actual results.  I'll do some more testing
when I get a minute.

Jon

signature.asc
Description: OpenPGP digital signature