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

[Øystein Johansen]

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

Yes, removing SAVE/FROMBASE is probably wise. Remember that it only 
gains when the whole vector (of four inputs) is zero. And the gain in 
general, before the vectorization, was about 5-10%. It can't gain much 
in the SSE evaluation.

> 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.

Sounds like a good idea. However I have no idea how it should be 
implemented to be MT-safe. Which model? Should both storing and reading 
be atomic?

> 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.

I haven't browsed the cache code much, this sounds more like a cuckoo 
scheme to me.

The cache is taken from Bob Jenkins archives. I'm not sure what 
differences that's made.

>  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.

What a double layer cache, there the value is kicked totally out if 
there's a crash in the second layer? That will increase the hit rate.

-Øystein