When running pragzip on an high-performance system managed with e.g. SLURM, only a subset of all cores might actually be usable. However, pragzip simply uses std::thread::hardware_concurrency, which does not account for that. Oversubscribing might degrade performance and increase the memory usage with no computational benefit. Furthermore, hardware_concurrency is supposedly only a hint and may also return 0, in which case only 1 thread will be used by pragzip. Both of these issues should be worked around by using the Linux-specific sched_getaffinity among others.
When running pragzip on an high-performance system managed with e.g. SLURM, only a subset of all cores might actually be usable. However, pragzip simply uses
std::thread::hardware_concurrency
, which does not account for that. Oversubscribing might degrade performance and increase the memory usage with no computational benefit. Furthermore,hardware_concurrency
is supposedly only a hint and may also return 0, in which case only 1 thread will be used by pragzip. Both of these issues should be worked around by using the Linux-specificsched_getaffinity
among others.