Open fo40225 opened 1 year ago
So far, I can't repeat this problem.
Furthermore, there were 6 bzip2 processed invoked but not counted.
Fastp sets 16-thread limit since 16-thread is always enough.
bgzip
is running concurrently, it didn't increase wall clock time.
According to Figure 1a in the paper, the algorithm should be able to scale out.
If I have time, I will help design some experiments and make improvements.
Is this repo still accepting pull requests?
I'm evaluating replacing our pipeline from trimmomatic to fastp, but fastp is slower than trimmomatic.
fastp: 2:18.08 trimmomatic: 1:09.35
fastp command:
fastp.log
trimmomatic command:
trimmomatic.log
OS: Ubuntu 22.04.1 LTS 5.15.0-58-generic
Hardware: 2x Intel Xeon Gold 6342 2TB RAM (16x 128GB DDR4-3200) 4x 4TB PCI-E 4.0 NVME SSD RAID 0
fastp is download from http://opengene.org/fastp/fastp.0.23.2 trimmomatic is download from http://www.usadellab.org/cms/uploads/supplementary/Trimmomatic/Trimmomatic-0.39.zip
Input and output files are placed on ramdisk (
/dev/shm
). Execute commands while the system is idle.I see
WARNING: fastp uses up to 16 threads although you specified 96
in log, what part of the algorithm limits the upper limit of 16 threads?