This version enables you to run multiple threads for SAMPE, all else are identical to the main release.
To check this is the correct version, please run
you should see -t INT number of threads  option in the list.
To use this -t option, please also use -P to preload files.
Be careful when you increase the thread number, each extra thread will cost 500+ MB memory, please ensure you have enough memory to run.
Here are some performance number as an example:
For a human PE run on 41,190,206 (read1 + read2) 83bp reads, single thread run of sampe costs: [main] Real time: 5953.375 sec; CPU: 4581.375 sec
With -t 16 -P: [main] Real time: 691.858 sec; CPU: 4596.500 sec , peak memory usage: 14.6GB
With -t 8 -P: [main] Real time: 729.719 sec; CPU: 4585.906 sec , peak memory usage: 12.7GB
With -t 4 -P: [main] Real time: 1309.683 sec; CPU: 4690.031 sec , peak memory usage: 10.0GB
Average memory usage is 2~3GB less than peak. So 8GB machines should be able to cope with -t 4. And you might try without -P, this will save some memory.
Due to the nature that sampe is reading many large files and writing a single sam file, I/O is not going to be parallelized, thus only a certain part can be. You might see from the numbers that reducing threads from 16 to 8 only slightly slowed the run time, apparently using more than 16 only give you a little margin. You may try out different numbers.
1, due to the parallel code call to random number function, picking one hit from multiple equally good hits will give you some different alignment compared with single thread run, this is correct behaviour, not a bug. (e.g. in the above example, there are 630,648 differences in the SAM file compared with single thread run, that's about 1.5%)
2, I didn't remove the debug output of threading information, for easier support. And it's interesting to look at. These only show up in stderr, not stdout, thus it won't affect the SAM file.