implementation of std::thread::hardware_concurrency()

Iain Sandoe developer@sandoe-acoustics.co.uk
Mon Nov 7 14:52:00 GMT 2011


On 7 Nov 2011, at 14:38, Jonathan Wakely wrote:

> On 7 November 2011 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" ..
>
> Does Darwin support those sysconf values?  AFAICT it doesn't.

from Darwin 9 onwards I believe so ..  (don't actually have a copy of  
Darwin11 yet).

>
> If not, we could find out the equivalent of HW_NCPU for
> "hw.logicalcpu" or just use sysctlbyname, but as Apple haven't
> documented it in the sysctl manpage I don't know if those sysctls are
> stable or reliable.
>
> If someone wants to improve the checks be my guest, as long as it's
> done via autoconf macros, not by making the macro mess in
> src/thread.cc any worse.



More information about the Gcc-patches mailing list