|
From: | Øystein Johansen |
Subject: | Re: FW: [Bug-gnubg] Simple multi-threading... Cache |
Date: | Wed, 24 Jan 2007 15:31:51 +0100 |
User-agent: | Thunderbird 1.5.0.9 (Windows/20061207) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |