bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] Re: Getting gnubg to use all available cores


From: Michael Petch
Subject: [Bug-gnubg] Re: Getting gnubg to use all available cores
Date: Fri, 07 Aug 2009 12:14:22 -0600
User-agent: Microsoft-Entourage/12.20.0.090605



On 07/08/09 11:45 AM, "Frank Berger" <address@hidden> wrote:

> Hi,
> 
> but under the given circumstances (OS X with 2 quad core Nehamlem)
> shouldn't be at least 4 Cores busy? I have to admit, that I have lost
> the motivation to follow the CUP-Specs, simply resignation by the
> sheer number of them and my disability to remember the funny code
> names or product numbering, but I would be very astonished if not all
> cores on 1 CPU are treated the same from the point of memory?
> 

In a NUMA architecture this isn't even guaranteed (Although with Intel
Nehalem configurations one would expect this is how it should work since
each processor has its own memory controller - not each core). It may be
Apple took the path of least resistance to implement this on  a threaded
scale. I'd make  a bet that if GnuBG forked processes (Instead of Threads)
and used shared memory that the result might be different on Leopard. I am
making a guess that without proper(full) Numa support at the Kernel level,
the Posix Threads implementation above it is inherently crippled depending
on application usage.

> On pre Nehalems BGB had no difficulties to keep 8 cores busy (although
> it scales not very well beyond 4 cores. Maybe the endgame DB is the
> culprit because it serializes all accesses) but I have no data about
> Nehalm CPUs.
>

GnuBG runs just fine on a Dual Quad Core FSB Intel Mac's utilizing all
processors under OS/X 10.5.x (SMP configuration where all processors and
cores share the same bus). I have access to just such a system. The issue in
question is specific to the Nehalem line.

There is a discussion on the CS4 forums along the same lines. People bought
the new Dual Core Nehalem Mac's and found that CS4 would only use about
10-15% of the available processor resources where as running on older FSB
Dual Quad Mac's utilized all 8 cores. When they dropped CS4 into a pre
release of Snow Leopard things were fine.

The first reports of  NUMA related issues surfaced out of Germany when
Nehalem based systems were available when testing was done against Apples
Leopard Xserve OS.







reply via email to

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