std::thread::hardware_concurrency() does not return the correct number of threads (system- and implementation-specific)

[daphne-eu]

In GitLab by @AhmedEleliemy on Sep 23, 2021, 16:38

According http://www.cplusplus.com/reference/thread/thread/hardware_concurrency/
The interpretation of this value is a system- and implementation-specific, and may not be exact, but just an approximation.
In a particular case, I reserved a node using the Slurm resource manager, the reserved node supported hyperthreading. However, in the reservation this option was disabled and the expected number of threads is supposed to be 20 threads, i.e., 20 physical cores. However std::thread::hardware_concurrency() returned 40.
Furthermore, when my job script requested 3 cores only, std::thread::hardware_concurrency() returned 40 as well.

[daphne-eu]

In GitLab by @pdamme on Sep 27, 2021, 13:27

Hi @AhmedEleliemy, thanks for catching this. Indeed, we should not rely on std::thread::hardware_concurrency. Instead, we should explicitly provide the number of threads to use by some means of configuration (see #141). In the simplest case, we could have a command line argument for the number of threads.

[jonnygiger]

This issue was recently discussed again and two suggestions were made:

• Use the hwloc library to query the system topology
• Parse the /proc/cpuinfo file (This is only going to work on Linux)

As an example, here is an implementation for finding the number of threads in Slurm (the entire function is in a huge ifdef statement with both implementations): xcpuinfo_hwloc_topo_get