[Bug-gnubg] Issues with evaluation cache locking

[Philippe Michel]

I recently had the opportunity to try to run gnubg on a 48-cores machine 
(running RHEL6).

This didn't work well when the number of threads became high : at around 
25-30 it hanged, usually almost immediately.

I replaced the locking code (for the evaluation cache only, not the 
multithreading in analysis or rollouts) with something using gcc builtins :
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
and as far as I could test that fixed the problem (and brought a small 
speed improvement whatever the number (>=2) of cores).

I don't know what compilers Michael uses for his binary builds, but the 
new code works as is with clang (on FreeBSD) and it is likely Intel or MS 
compilers have the same functionality with at worst minor differences in 
API.

It is currently Intel-specific and it is not clear if it would be useful 
for other processors. Gcc claims to emulate these functions if they are 
not native on the target CPU, but then the resulting code may not 
necessarily be better than that from Glib.

More broadly, it looks like this locking is rather expensive. With only 2 
or 4 cores and (I think) little or no contention, the locking is 30+% of 
the time used by the CacheLookupWithLocking() function. That is with the 
new locking code, it was probably significantly worse before.

This is still not much compared with inputs or neural net computations, 
but implementing something like this :
http://www.cis.uab.edu/hyatt/hashing.html
would be cleaner and avoid scalability trouble.