![]() Over-specifying the number of threads is not a catastrophically bad thing to do, and you can use cgroups or hwloc-bind to govern how many cores the entire process can take up too.Īlso I don't think it's true to say that samtools sort only uses more than one CPU until the mapper has finished. However this particular problem is perhaps one of expectation. ![]() ![]() Ideally it would be using asynchronous I/O too. I guess the single thread for the first phase could nicely fill the missing CPU utilization of the mapper.the currently suboptimal performance of samtools sort during reading would be nicely hidden.the CPU usage could be better limited (in shared environments you need to specify the number of cores and sometimes admins really check).Until the mapper is finished samtools could for instance use a single thread for reading and chunking and then use the full number of threads afterwards (when the mapper has finished). This would simplify the specification of the number of threads used by both programs. I suggest to allow to specify the number of CPUs used by samtools during reading the data (and producing pre sorted chunks) separately. Until all data is read entirely samtools seldomly uses the available CPUs efficiently (CPU usage is seldomly larger than 100%).When using mapper | samtools sort - it is difficult to specify the number of threads for the mapper and for samtools.Is your feature request related to a problem? Please specify.
0 Comments
Leave a Reply. |