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

[Jonathan Kinsey]

Jonathan Kinsey wrote:
> 
> 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!...

I think it might be ok to remove this optimization for the sse code - I
didn't notice any difference when I tried this (just calling
Evaluate128() every time).  Can someone with a less messed up code base
run a test to see if this code does benefit when SSE is enabled?

With this removed I seem to get the correct result reliably with
multiple threads, but this is with the cache guarded - and this causes
lots of contention (threads waiting for each other).  A solution is to
rewrite the cache code to have a single entry per hash, and then
multiple threads can write to the cache at the same time.

The current cache has a simple "two slot" approach, in that if a hash
clashes the old hit is put in a back up slot; furthermore if the 2nd
slot is hit then it's swapped with the 1st.  With a single slot approach
there will be more cache misses (but the cache code will be slightly
quicker), some more performance testing is needed - a bigger cache than
the default 65536 would probably minimise the difference...  The other
approach is a separate cache per thread - I imagine this would be much
less effecient.

I think these are the final issues in getting the multi-threaded code
working correctly (I've got a work around for the mingw SSE stack
alignment problem).

Jon

signature.asc
Description: OpenPGP digital signature