2026-09-16
pydreg is a Python port of dREG. On 12 libraries, peaks match at Jaccard > 0.997, runtime drops ~4.5×, and peak RAM falls 5.4×.
dREG still ranks among the more accurate callers of active promoters and enhancers from GRO-, PRO-, and ChRO-seq. The reference code is the problem: R, C, shell, and a pile of genomics binaries, with GPU support gated on Rgtsvm built from CUDA and Boost. Rgtsvm targets early NVIDIA hardware and sparse workloads. Several critical dependencies have not been touched in more than five years. Local installs have become a research project of their own.
pydreg does not propose a new caller. It moves the same pretrained models and the same peak-calling procedure onto a stack that can be pip-installed and that can use dense GEMM.
The pipeline matches current dREG. Informative genomic positions are selected, multi-scale coverage is packed into a 360-D feature, the original RBF-SVR (605,187 support vectors) scores every site, high-scoring neighbours are stitched into peaks, the original random forest splits them, and a correlated 5-D Laplace null with Benjamini-Hochberg FDR (p ≤ 0.05) filters the list.
Weights are converted from RData to safetensors and cached on first run. GPU scoring uses CuPy on NVIDIA and MLX on Apple silicon; CPU fallback is NumPy plus Numba. Query batches are multiplied against support-vector chunks via ‖x−s‖² = ‖x‖²+‖s‖²−2xᵀs, a fused kernel applies the RBF, and dual coefficients weight the result. I/O and feature extraction prefetch so they no longer stall between GPU batches.
For each candidate summit, five smoothed scores are tested under the Laplace null with quasi-Monte Carlo. pydreg skips zero-weight grid points and stops the integral once the remaining tail cannot exceed 10⁻⁶, cutting QMC evaluations by about half. The authors report no practical change in the statistics.
Coding agents (Claude Code with Opus 4.6/5 and Sonnet 5; Codex with GPT-5.5) wrote the codebase. The authors chose the ports and ran the benchmarks.
Twelve published GRO/PRO/ChRO-seq libraries, 126,442,569 candidate positions, Titan Xp plus 16 CPU threads. SVR scores match at Pearson r > 0.999, MAE 0.00251, max |Δ| 0.0256. Peak Jaccard is above 0.997. Wall time is about 4.5× lower. Peak host RSS drops 3.8–6.8× (median 5.4×).
Nsight: pydreg does 12× more work per kernel launch and 942× more per H2D copy. Scoring-phase wall time is 5.5× lower (G1: 7,567 s vs 1,354 s). Mean GPU utilization rises from 67% to 95% because feature extraction no longer runs serially with GPU batches. GPU-active compute is still 4.2× shorter, so the GEMM path itself is cheaper, not only the schedule.
No new sequencing data. No accuracy bake-off against newer CRE callers. The reference is original dREG.
This is maintenance, done carefully. Groups still hitting the dREG gateway or compiling Rgtsvm can pip install pydreg[gpu], emit BED/bigWig, and fold calling into Python workflows. Site-level scores essentially overlay, so the migration risk is low. For GPU inference, it is a clean case of replacing sparse-oriented custom CUDA with dense GEMM and watching utilization climb from two-thirds to near saturation.
Funded by Astera's Hidden Science competition; the authors decline journal submission under the open-science policy, so the bioRxiv posting is the version of record.
The algorithm is unchanged, including the ceiling of a 2010s RBF-SVR with hand-built 360-D features and 600k support vectors. There is no CPU-only or consumer-GPU end-to-end timing, and no sensitivity comparison with newer deep callers. Early stopping of QMC is claimed not to matter, without a separate calibration table. Agents wrote the code; reproducibility sits on the public repo and cached weights, not on a module-by-module human audit in the paper.