Re: gthread: how many cores do I have?

["Freddie Unpenstein" <fredderic excite com>]

From: "Pavel Machek", Date: 02/04/2010 23:28

> On Mon 2010-03-15 17:15:01, Tor Lillqvist wrote:
>> Anyway, I didn't suggest using "CPU" but "processor". Existing
>> platform APIs traditionally use the term "processor" and not "core"
>> for this, like sysconf(_SC_NPROCESSORS_ONLN) on Linux and
>> SYSTEM_INFO.dwNumberOfProcessors on Windows.
> Well, some people use 'processor == the thing that fits into cpu
> socket'. 'Core' got only popular recently, but is not ambiguous.

Personally, I rather agree.  Processors might be the traditional term, but traditionally (as in when the term was conceived), there were no multi-core processors in common use.  So while "cores" might be a more recent term, that's only because it's a more recently useful concept.

I'm only throwing my 2c in on this topic, because I'd think what the API should be counting is simply how many threads of this application could conceivably be running simultaneously.  Any other measure should be left to a more general system information interface (eg. one that individually numerates each processor and its featues, the cores on that processor and their features, and so forth).

For example, if I've got two duel-core processors, I'd like to know that I can run 4 threads simultaneously.  I don't really care whether it's one chip with four cores, or two chips with two cores each.  And if I *DO* care, I probably need to know a fair bit more than just the count anyhow.


> And then the valid question is... should the api also count virtual
> cpus from hyperthreading (aka smt?)?

BOTH should be available.  If we're spinning up threads to perform some processing, then we need to count those virtual cores.  But if we're starting a child program to perform some processing, then we need to know the count of real cores instead.


Having s

Fredderic