Getting # Physical CPUs

Georg Wrede Georg.Wrede at iki.fi
Sat Jul 17 18:15:31 PDT 2010


On 07/16/2010 04:48 AM, Don wrote:
> Georg Wrede wrote:
>> On 07/14/2010 08:55 PM, dsimcha wrote:
>>> 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.

True. What my app needs D to tell it, is to enumerate and specify the 
processors (and of course any other variable resources) available to 
this particular instance of running program.

>> (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).

Agreed.

Runtime initialization code should find out the resources available to 
the current app instance. Anything else can (or should) be available 
from /proc/... (or, whatever equivalents Bill G or Steve J have 
decided), and the app is free to roam around in that directory tree.


More information about the Digitalmars-d mailing list