On 07/14/2010 08:55 PM, dsimcha wrote:
== Quote from eris ([email protected])'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.
(A case in point, at bootup, the Linux core already enumerates and
evaluates each found core individually.)
