Re: implementation of std::thread::hardware_concurrency()

[Iain Sandoe <developer at sandoe-acoustics dot co dot uk>]

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]

Iain