On Tue, Aug 29, 2017 at 2:58 AM, James Bonfield <j...@sanger.ac.uk> wrote:
> On Sun, Aug 27, 2017 at 12:08:16PM -0600, Brent Pedersen wrote:
>> hi, it seems that if I call without l hts_set_threads, I get, as
>> expected 100% cpu for a process that is reading a BAM or CRAM.
>> If I call it with nthreads = 1, I get 100% cpu.
>> If I call it with nthreads = 2, I get 300% cpu.
>
> Is this with htslib 1.5? The way the threading works is it spawns
> additional threads to main for handling the compression and
> decompression. So I'd expect 1 thread to mean up to 200% cpu
> permitted.
>
> For BAM files I see in bgzf_mt() this code:
>
> if (n_threads < 1) return -1;
> hts_tpool *p = hts_tpool_init(n_threads);
>
> So in theory n_threads of 1 should be enough to be using the thread
> pool. CRAM's equivalent is in cram_set_voption in cram/cram_io.c,
> although I see that has an error here:
>
> case CRAM_OPT_NTHREADS: {
> int nthreads = va_arg(args, int);
> if (nthreads > 1) {
> if (!(fd->pool = hts_tpool_init(nthreads)))
> return -1;
>
> That should probably read "nthreads >= 1" for consistency.
>
> Do you see any difference in BAM vs CRAM at nthreads of 1? Does
> changing that line above to >= solve it for you with CRAM?
>
> James
You are right on both counts; wIth BAM, it was working as expected.
With CRAM, after that change, it is solved.
thanks,
-Brent
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Samtools-help mailing list
Samtools-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/samtools-help
