henhaobio
Sign in

GigabyteBioinformaticsPeer-reviewed journal article

vardictcpp: A C++ reimplementation of VarDict variant caller

Joachim WolffiD

PDFDOIPreprintCode

In-depth summary

Claude Opus 5.5 · xhigh effort · 8 Nov 2026 · from the full text of version 1 (24 Sept 2026) · CC BY 4.0

An AI-assisted C++17 port of VarDictJava gives byte-identical calls on five exome samples while running 3.7-4.8 times faster on one core and needing 8-17 times less memory.

VarDictJava, which the author uses for ultra-low variant allele frequency calling in measurable residual disease (MRD) monitoring, can use large amounts of memory (over 100 GB when -R covers a whole chromosome), which limits how many jobs run in parallel per node. vardictcpp keeps its command line, defaults and VCF output as a drop-in replacement, and attributes its gains to native code and compact per-position data structures rather than to any change in the calling algorithm.

Key results

  1. Shownvardictcpp reproduces VarDictJava output exactly. Its default-mode VCF rows were byte-identical on all five tested samples, its somatic tumor-normal call set was identical, and it scored the same as VarDictJava against the GIAB truth set.

    Table 1: sorted output matched VarDictJava 1.8.3 line-for-line on five hg19 WES samples (-f 0.01). On GIAB HG002 chromosome 20 (NIST v4.2.1 truth set, rtg vcfeval, 2 443 truth variants), both implementations reach SNV F1 0.985 and indel F1 0.801, vs octopus 0.993 (SNV) and 0.907 (indel) and FreeBayes 0.829 (indel). · Abstract; 3 Results and Discussion; Tables

  2. ShownAgainst VarDictJava 1.8.3 on the same exome samples, vardictcpp is several times faster and uses far less peak memory, both single-threaded and with 8 threads.

    1 core: 3.7-4.8 times faster, 8-17 times less memory (SRR15006376: 44 s and 74 MB vs 181 s and 1.2 GB). 8 cores: 9.3-11.0 times faster, 7-8 times less memory (SRR15006376: 7.8 s and 358 MB vs 85 s and 2.6 GB). Median of 5 CPU-pinned runs on AMD Ryzen 7950X; VarDictJava on JDK 25 with -Xmx 8g. · Abstract; 3 Results and Discussion; Tables

  3. ShownPassing all of chromosome 1 as one -R region raises memory in both tools. vardictcpp stays at 10.6 GB, while VarDictJava needs 107 GB, more than most compute nodes have.

    MV4-11 (SRR8657348), -R chr1:1-249250621: vardictcpp 2:03 and 10.6 GB vs 14 s and 252 MB for the 8-core targeted run; VarDictJava about six minutes and 107 GB vs two minutes and 2 GB, a 43-fold vs 53-fold memory increase. VarDictJava runs out of memory at -Xmx 4g on this region. · 1 Statement of Need; 3 Results and Discussion; Tables

  4. ShownOn the tumor-only MV4-11 sample at VAF 0.01, vardictcpp was the fastest of six callers both single-core and on 8 cores. In somatic tumor-normal mode it was also the fastest and used the least memory.

    SRR8657348 (773,667 target regions), AMD Epyc 9654: single-core 2:21 min; the text names VarDictJava (around eleven minutes) as next closest, though it also gives about 5-17 min for the other tools. 8 cores: 19 s vs FreeBayes 44 s (next fastest) and octopus 18:57. Somatic (SRR15006376 vs SRR15006386): 3:04 single-core and 35 s on 8 cores vs VarDictJava 9:40 and 5:03. · 3 Results and Discussion; Figure legends

  5. SuggestedClaude Code agents (Claude Opus 4.8) wrote the port by translating the Java modules into C++, checked against a byte-level parity test. It took 12 calendar days of part-time work.

    The agents were required to match only the CLI, inputs and outputs. Per-module differences from VarDictJava were triaged until the VCF rows agreed in all 36 columns for SNVs, MNPs, indels, complex and structural variants, at -f 0.01 and -f 0. VarDictJava, itself a port, took 143 calendar days from first commit to first release; the author notes this bounds calendar time, not effort. · 2 Implementation; 3 Results and Discussion; 6.5 Use of generative AI in manuscript, figure…

Methods, data and reproducibility

VarDictJava was translated module by module into C++17 with Claude Code agents, using htslib in place of HTSJDK and keeping the CLI, defaults and VCF format. Output parity was checked on full rows. Runtime, peak RSS and calls were then benchmarked against VarDictJava 1.8.3 and four other callers on public AML exome data and GIAB HG002.

  • Adult AML bone marrow samples carrying FLT3-ITD (SRR15006375, SRR15006376, SRR15006386, SRR15006540; Illumina MiSeq), from the FiLT3r study · human (adult AML bone marrow; hg19 reference) · n = 4 samples · BioProject PRJNA742684
  • MV4-11 AML cell line from the Cancer Cell Line Encyclopedia (SRR8657348), 773,667 target regions · human (MV4-11 cell line, CCLE; hg19 reference) · n = 1 cell line · BioProject PRJNA523380
  • Genome in a Bottle HG002 germline exome (Agilent SureSelect v5), chromosome 20, high-confidence exome-callable regions (depth >= 20), NIST GIAB v4.2.1 truth set · human (GIAB HG002 reference sample) · n = 2.31 Mbp; 2 443 truth variants
Methods & tools
vardictcpp, VarDictJava 1.8.3, htslib, Claude Code (Claude Opus 4.8), FreeBayes, LoFreq, Mutect2, octopus, rtg vcfeval, NIST GIAB v4.2.1 truth set, Bioconda, Galaxy
Software & environment
C++17, CMake >= 3.15, htslib >= 1.10; Bioconda package and Galaxy tool wrapper; Linux (x86-64, ARM) and macOS (Apple Silicon); benchmarks on Ubuntu 24.04 with VarDictJava 1.8.3 on JDK 25; MIT licence.
Assay conditions & compute
AMD Ryzen 7950X (16 cores, 128 GB RAM) for Tables 2-3 and AMD Epyc 9654 (96 cores, 1.1 TB RAM) for Figure 1; wall clock and peak RSS from /usr/bin/time -v, median of 5 CPU-pinned replicate runs (Table 2).
Reproducibility gaps
Raw data are public under BioProject PRJNA742684 (SRR15006375, SRR15006376, SRR15006386, SRR15006540) and PRJNA523380 (SRR8657348); see methods.data. The cited Zenodo archive (BAMs, truth sets, caller outputs, benchmark scripts) has no DOI or URL printed.
Limitations (5)
  • The somatic tumor-normal comparison has no orthogonal truth set. Figure 3 shows agreement between callers, not accuracy, and the 606 VarDict-only calls could reflect either higher sensitivity at low VAF or more false positives. · stated by the authors
  • The 12-day AI-assisted port is a single and unusually well-posed case (fixed CLI, complete reference implementation, automatable byte-level check). The comparison with VarDictJava's 143 days bounds calendar time, not effort, and the two releases may differ in functional scope. · stated by the authors
  • Whole-chromosome -R runs still raise vardictcpp memory 43-fold (10.6 GB), because per-position maps span the full chromosome whatever the -f setting. · stated by the authors
  • Parity and benchmarks rest on five hg19 exome samples (four from one MiSeq AML BioProject plus one cell line) and GIAB chromosome 20; no whole-genome data are tested. · noted in this summary
  • The exome runtime and memory figures (Table 2, Figure 1 top) use -f 0.01, and the somatic panel does not state its -f. The -f 0 MRD setting that motivates the work is covered by the parity checks, but its exome-scale runtime is not reported. · noted in this summary

Read this if you run VarDict or VarDictJava in a clinical or high-throughput pipeline and are limited by memory or turnaround, or want a worked example of porting scientific software with AI coding agents against a reference implementation.

Citations
1
FWCI
2.04
Field percentile
top 10%

Abstract

Genomic variant calling is a central computational task in disease research and diagnostics, where somatic mutations such as JAK2 V617F serve as diagnostic markers in myeloid neoplasms. VarDict, originally written in Perl, and its reimplementation VarDictJava are widely used variant callers in the bioinformatics community. The Perl implementation requires run times of up to several hours; VarDictJava reduces this to a few minutes but can consume large amounts of main memory, which limits the number of jobs that can be run in parallel on a given machine. We present vardictcpp, a functionally identical reimplementation of VarDictJava in C++17. vardictcpp is approximately four times faster in single-core execution and 9-11 times faster using eight cores, while requiring up to 17 times less main memory. Variant calls are identical to those of VarDictJava on the evaluated whole-exome samples. The reduced memory footprint allows more concurrent jobs on existing hardware and thereby increases sample throughput, which is particularly relevant for clinical sequencing laboratories with fixed compute resources. vardictcpp is implemented in C++17 and freely available at https://github.com/MHH-Bioinformatics-Hematology/vardictcpp

Reproducibility ledger

Nobody has reported trying to reproduce this paper yet. Did you replicate an experiment or run the code? Your report saves the next lab a week.

Sign in to file a reproducibility report.

Related papers

Similarity Map
SelectedSame fieldCross-field
THISLi '24Pedersen '24Sun '16KP '26Barasiya '25Ghareghani '16
68% semantic matchBioinformatics
Zilong Li·Bioinformatics·Jan 23, 2024· 6 citations