On Wed, Apr 21, 2021 at 08:53:54PM +0100, Jonathan Wakely wrote:
> > > What would be IMHO a good idea would be to use configure test for
> > > #include <thread>
> > > int t = std::thread::hardware_concurrency ();
> > > and in that case use that as a fallback to the previous implementation,
> > > that will be strictly an improvement.
> >
> > That does not make sense to me. Original motivation was removal of the
> > complicated
> > implementation with a C++ standard function.
The reason it is larger and more complicated is that it answers a different
question than std::thread::hardware_concurrency().
hardware_concurrency() says how many threads the hw has available, if we
wanted just that, you could just keep the sysconf call.
The current implementation answers the question how many threads can this
process and its children be scheduled on.
Consider some NUMA box with hundreds of threads, but where it might
be desirable to keep specific compilations limited to some cores and do
other compilations or whatever else on other cores.
Sure, hardware_concurrency() answer is better than no information about the
concurrency at all. But I don't really see the costs of the current
implementation, it is < 100 lines of code that have been written once and
it is unlikely they will need changing - at this point the interfaces are
fairly stable, haven't been changed on the glibc side for years. It is true
that when it was introduced in glibc, there have been 2 big changes to it
soon.
Jakub
