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
--
James Bonfield (j...@sanger.ac.uk) | Hora aderat briligi. Nunc et Slythia Tova
| Plurima gyrabant gymbolitare vabo;
A Staden Package developer: | Et Borogovorum mimzebant undique formae,
https://sf.net/projects/staden/ | Momiferique omnes exgrabure Rathi.
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
------------------------------------------------------------------------------
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
