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

[Jonathan Kinsey]

Been a bit busy for the last week or so, seems like the break was good
for me though as I've found a solution for the cache contention problem.

Windows gives you 3 synchronization approaches, the first is kernel
level mutexes, which perform really badly in this high hit code area -
in my 51 move test game it's called 3 million times; Consider base times
of 28.4 for 1 thread and 14.9 for 2 threads (90% faster) with no
synchronization.  Then with mutexes this becomes 41.3 and 40.5, in other
words the kernel level context switches are very slow (and 2 threads
doesn't help at all!).

Next up is user level mutexes (critical sections), these fair a bit
better at 28.5 and 20.6 (1 and 2 thread resp.).  So at least the single
threaded code is the same and the dual threaded code a bit faster.  The
high contention on the cache is having a big effect though.

Now the final approach is InterlockedIncrement/Decrement operations
(basically thread safe ++ -- operations).  This allowed me to have a
lock for each cache entry, and obviously the contention on individual
entries is very low.  On a different machine, the base times are now
(31.4 and 16.4) and with the locking 31.9 and 16.8.  So setting/clearing
the locks has about a %1.5 hit - I think this is the best I can do at
the moment.


I can tidy the code up and check it in (probably at the weekend), I'm
not sure if unix/glib has an equivalent for the InterlockedIncrement
function.  Could just use ++ and -- operators, just asking for trouble
when the very unlikely happens and two threads happen to do this at
exactly the same time for the same cache entry (the read/write of these
operators isn't atomic).

Jon

signature.asc
Description: OpenPGP digital signature