Getting # Physical CPUs

[Don]

Georg Wrede wrote:
> On 07/14/2010 08:55 PM, dsimcha wrote:
>> == Quote from eris (jvburnes at gmail.com)'s article
>>> This is a relatively difficult problem in general to do portably due 
>>> to hardware
>> differences, topology differences, changes to hardware, OS 
>> variations.  Even the
>> pthreads library doesn't reliably implement it in a portable manner.
>>> I came to the conclusion that the people most motivated to keep up to 
>>> date on a
>> portable CPU core topology are the national supercomputing labs.  
>> INRIA and
>> various US labs came up with "Portable Hardware Locality" library.  It 
>> gives you
>> *everything* you need to discover the number of CPU sockets, memory 
>> architecture,
>> number of cores per socket, control cpu affinity etc.
>>> The HWLoc C libraries are written by the open-mpi project here:
>> http://www.open-mpi.org/projects/hwloc/
>>
>> I appreciate the help, but honestly, if detecting this properly 
>> requires adding
>> dependencies to my projects, I'm happier with the simple workaround of 
>> having a
>> manual command line switch to specify the number of CPUs.  The 
>> projects in
>> question are internal research projects, not things that are going to 
>> be released
>> on the computer-illiterate masses.  It would be nice to not have to 
>> manually
>> specify such a parameter on every run, but not nice enough to be worth 
>> introducing
>> a dependency.
> 
> I can't imagine how this would not be a required part of the core library.
> 
> For a language that claims to be thread savvy, knowing the number of 
> cpus and the number of cores, is simply obligatory homework.
> 
> An extra point: the code that identifies them, should not ever assume 
> that all cores are identical. Nor that they have identical access to 
> machine resources.

> The day that someone invents the 'unequal cores paradigm', where cores 
> of dissimilar power are included in the same computer, should not expose 
> us with our pants down.

It really depends on what the purpose is. If you want to determine the 
precise core topology, the available information is heavily 
OS-dependent. Note that there's potentially a large difference between 
the number of cores in the machine, versus the number of cores which the 
OS makes available to your app. Generally the second number is the one 
which matters.

> (A case in point, at bootup, the Linux core already enumerates and 
> evaluates each found core individually.)

Of course it does. It's trivial when you're an OS and have unrestricted 
access to the machine. An app is severely limited to what it can get 
from the OS.

Currently core.cpuid doesn't make any OS calls at all.
I think std.cpuid should be replaced with a new module std.sysinfo, 
which determines more features (such as available RAM).