On 7 November 2011 14:40, Iain Sandoe wrote:
>
> On 7 Nov 2011, at 14:23, Iain Sandoe wrote:
>
>> On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
>>
>>> On 7 November 2011 14:10, Iain Sandoe wrote:
>>>>
>>>> On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
>>>>
>>>>> This provides a working thread::hardware_concurrency on platforms that
>>>>> support pthread_num_processors_np or the "hw.ncpu" sysctl, but by
>>>>> testing for the features in configure rather than hardcoding OS macro
>>>>> tests in thread.cc
>>>>
>>>> if the system supports run-time User-controllable core-count then this
>>>> will
>>>> not account for that.
>>>
>>> Yep. Do you know how to detect the right value in that case? If not
>>> the alternative is to revert to the previous behaviour of returning
>>> zero.
>>>
>>> (My understanding was that at least some of the options would work for
>>> that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for
>>> example)
>>
>> Hm. I don't know about the general case - on Darwin it's certainly
>> possible to get at the information at runtime;
>>
>> hw.logicalcpu_max: 4
>> hw.logicalcpu: 4
>> hw.physicalcpu_max: 4
>> hw.physicalcpu: 4
>> hw.ncpu = 4
>>
>> and ... switching the control panel to dual CPU ..
>>
>> hw.logicalcpu_max: 4
>> hw.logicalcpu: 2
>> hw.physicalcpu_max: 4
>> hw.physicalcpu: 2
>> hw.ncpu = 4
>>
>> but, as you say, that would be the implication of "ONLN" vs "CONF" ..
>
> however, apparently not - ...
>
> #include <unistd.h>
> #include <stdio.h>
>
> int main (int ac, char *avv[])
> {
> printf ("n-procs: %d\n", sysconf (_SC_NPROCESSORS_ONLN));
> }
>
> $ gcc-4.2 ../tests/nprocs.c -o tt
>
> ./tt
> n-procs: 4
>
> .. switched to dual cpu ...
>
> $ sysctl hw.logicalcpu
> hw.logicalcpu: 2
>
> $ ./tt
> n-procs: 4
>
> :-(
>
> so there's a reason to use the systlbyname (and use hw.logicalcpu or
> similar, maybe).
> [unless that's just a buggy sysconf]
Well if that's how they want to play it then I'm not even going to
think about changing that code without being able to test it on a real
system!
What does "switch to dual cpu" actually mean? disable hyperthreading?
disable one core on each die to save power? disable one die to save
power? lie about number of cores so buggy software doesn't get
confused?
I think someone with access to a darwin box and motivation to improve
it will have to make any improvements. I would suggest using
sysctlnametomib and caching the result, then using sysctl, to avoid
the overhead of systlbyname parsing the name on every call. At some
point in the near future (no pun intended) I want to enhance
std::async so it checks the system load and maybe the
hardware_concurrency when deciding whether to run an asynchronous task
in a new thread or not, so I want thread:hardware_concurrency() to be
as fast as possible.
