wtpoa-cns not using all requested threads about wtdbg2

[lh3]

PS: I should add that the issue may depend on available RAM and other processes running on the same machine. On a just rebooted machine or on a machine with lots of free RAM, the issue may be alleviated.

[lh3]

PSS: I have updated the precompiled binaries in the release page. wtdbg2, wtdbg-cns and wtpoa-cns in the binary tar-ball are now statically linked to TCMalloc. They are faster on my machine. Not sure if you can see the difference on your side.

[ruanjue]

Dear Heng,

wtpoa-cns and wtdbg-cns used the same schema in paralleling. They take one contig and break the task into mutiple parallel parts naturally according to edges in wtdbg, then merge the consensus edge sequences into the contig sequence.

If paralleling in contigs instead of edges within contig, the CPU usage will be expected as -t 16. But my concern was the various contig lengths might leave some threads run much much longer than others.

Another way might be seprating the 'edge consensus sequence' and 'merging edges'. For all contigs, we first build consensus edge sequences and write a prefix.ctg.lay.edges.fa file, it will take full CPU usage. Then, merging, it also will take full CPU usage. Let me try it.

[lh3]

On my machine, the problem is not caused by some threads running longer. Using tcmalloc wouldn't help in that case. I believe the slowdown is due to frequent malloc calls. I have seen similar behaviors a few times before.

[ruanjue]

Hi Heng,

You are right, the frequent malloc calls slowed down multi-threads. I have located the causal codes.

Thanks very much!
Jue