[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 :
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 :
would be cleaner and avoid scalability trouble.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]