Poor benchmarking to FastTree?

[DntBScrdDv]

Hi,

Thanks for putting this tool together; on the face of it very useful for me and my 40K OTUs!

However, in the two cases I've tried I've got significantly worse performance than FastTree (see below).

MAFFT
mafft --auto --thread 32 --reorder clustering.fasta > clustering.aln.fasta

39286 sequences aligned in ~45 minutes
Output: clustering.aln.fasta (1,822,105,662 bytes)

VeryFastTree
VeryFastTree -nt -gtr -double-precision -threads 32 -log veryfasttree.log clustering.aln.fasta > clustering.nwk

VeryFastTree Version 4.0.5 (OpenMP, AVX2) Double precision with AVX2 using threads(32) level 3 deterministic
Total time: 5641.05 seconds
Unique: 39286/39286
Bad splits: 38924/39283
Worst delta-LogLk: 63.525

FastTree
FastTree -nt -gtr -log fasttree.log clustering.aln.fasta > clustering.nwk

FastTree Version 2.2.0 Double precision
Total time: 30864.29 seconds
Unique: 39286/39286
Bad splits: 217/39283
Worst delta-LogLk: 17.653

A similar finding was seen with the other run (single precision):

VeryFastTree -nt -gtr -threads 64 -log veryfasttree.log clustering.aln.fasta > clustering.nwk

VeryFastTree 4.0.5 (OpenMP, AVX2) -- no "Double precision" banner
Bad splits: 11,041 / 11,261 (98.0%)
Worst delta-LogLk: 43.56
Final LogLk: -2,093,073
Min non-zero branch len: 0.00050 (hard floor)
Branches with BL < 1e-5: 0

FastTree -nt -gtr -log fasttree.log clustering.aln.fasta > clustering.nwk

FastTree Version 2.2.0 Double precision
Bad splits: 70 / 11,261 (0.6%)
Worst delta-LogLk: 16.37
Final LogLk: -2,086,757
Min non-zero branch len: 0.00000
Branches with BL < 1e-5: 792

So presumably not something to do with the input files...

[cesarpomar]

Thanks a lot for the detailed report and for trying VeryFastTree.

The behavior you’re observing is not expected. While it is true that higher parallelization levels (3, and even more so level 4) introduce more aggressive changes to the execution of the algorithm, in most cases this should only have a minor impact on the resulting topology.

In particular:

• For threads-level 3, any degradation in quality should typically be recoverable by increasing the number of NNI rounds.
• For threads-level 4, which is more aggressive, similar effects may appear, but they should generally be mitigated by increasing the number of SPR rounds or path length.

The high proportion of bad splits (~98–99%) that you report is therefore a strong indication that something is not working as intended in this specific case.

If possible, it would be helpful if you could share a reduced version of your dataset (as small as possible, but still reproducing the issue). With that, we can perform a more detailed debugging process to identify exactly where things are going wrong.

Thanks again for the report.