On 14/07/2011 4:09 PM, Philippe Michel wrote: > 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. > This confirms a finding that someone made to me on a high end MAC system. In fact you can get this hang on systems with fewer processors, but at least it is confirmed.
> 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. > I use GCC 4.5.2 for the windows builds. > 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. > I could test this on a PPC based system. Unfortunately the GCC I use for the older systems may have to be updated. I had intentions of doing another build this weekend given there have been a few bug fixes the past week or so, and will porbably do builds for MAC and Windows. Michael _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
