when -j is not specified, the default number of threads is multiprocessing.cpu_count() which is the number of cpu in the machine. But this is not the same as the number of cpu available to the process. For example, you can run virsorter using taskset or a batch scheduler like slurm.
If I run virtsorter on a 96 cores machines in a single core slurm allocation, 96 threads will be spawned and fight for a single core. A solution would be to use os.sched_getaffinity instead of multiprocessing.cpu_count on platform supporting it:
Hello,
when -j is not specified, the default number of threads is multiprocessing.cpu_count() which is the number of cpu in the machine. But this is not the same as the number of cpu available to the process. For example, you can run virsorter using taskset or a batch scheduler like slurm.
If I run virtsorter on a 96 cores machines in a single core slurm allocation, 96 threads will be spawned and fight for a single core. A solution would be to use os.sched_getaffinity instead of multiprocessing.cpu_count on platform supporting it:
What do you think ?