[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnubg] Issues with evaluation cache locking
From: |
Philippe Michel |
Subject: |
[Bug-gnubg] Issues with evaluation cache locking |
Date: |
Fri, 15 Jul 2011 00:09:41 +0200 (CEST) |
User-agent: |
Alpine 2.00 (BSF 1167 2008-08-23) |
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.
- [Bug-gnubg] Issues with evaluation cache locking,
Philippe Michel <=