Pith. sign in

REVIEW 4 major objections 4 minor 26 references

traccc: GPU track reconstruction library for HEP experiments

T0 review · 4 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that traccc, a GPU-resident implementation of the standard HEP track reconstruction chain, reproduces CPU physics performance closely while achieving higher event throughput than the CPU for sufficiently large events.

desk verdict A genuinely useful engineering status report for GPU track reconstruction, but the abstract overclaims FP32 physics agreement and needs a toned-down claim plus GPU efficiency numbers before acceptance. read the letter →

arxiv 2505.22822 v1 pith:XBVNJJSR submitted 2025-05-28 hep-ex

Paul Gessinger , Heather M. Gray , Attila Krasznahorkay , Charles Leggett , Joana Niermann , Andreas Salzburger , Stephen Nicholas Swatman , Beomki Yeo This is my paper
classification hep-ex
keywords GPUcomputingtrackreconstructioncombinatorialKalmanfilterHL-LHCCUDASYCLeventthroughput
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

traccc is a GPU-native implementation of the standard HEP track reconstruction chain, including clustering, seeding, combinatorial Kalman filter (CKF) track finding, and Kalman-filter fitting with RTS smoothing. The paper's central claim is that this GPU chain reproduces the CPU physics almost exactly while computing faster: CKF track patterns match in 94.7% of cases with FP32 and 99.4% with FP64, and the RTX A6000 beats the CPU in event throughput for most pileup values in FP32. The authors argue this makes GPUs a viable path to meeting the track reconstruction demands of HL-LHC, where CPU-only computing is expected to fall short. The paper is explicit that work remains, including ambiguity resolution, a more stable smoother, and better handling of concurrent event pipelines.

What carries the argument

The central object is traccc, a C++ library implementing a GPU-friendly version of the track reconstruction chain, and its core algorithm is the combinatorial Kalman filter (CKF), which propagates track candidates through detector layers and attaches compatible measurements by a $\chi^2$ gate. The chain is completed by a Kalman-filter fit using the Rauch-Tung-Striebel (RTS) smoother, with track parameters propagated by a fourth-order Runge-Kutta-Nyström method. Sparse hit clustering is handled as a connected-component analysis solved with FastSV, and the design keeps per-event host-device transfers down to pixel hit input and fitted parameter output, with geometry and magnetic field transferred once.

What would settle it

Repeat the benchmark with a Geant4 simulation in which material interactions use the true particle species instead of a muon assumption for all tracks, and compare tracking efficiency and GPU/CPU event throughput; a significant change in either would indicate the current result depends on the material approximation. A second check would be to replace the RTS smoother with a more stable alternative and test whether FP32 fitted-parameter matching rises substantially.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that a fully GPU-resident track reconstruction chain can deliver the same tracking performance as CPU code while exceeding CPU throughput on sufficiently large events. The CKF pattern-finding output is identical between GPU and CPU in 94.7% (FP32) and 99.4% (FP64) of tracks; fitted track parameters agree less often in FP32, which the authors attribute to numerical instability in the RTS smoother. In throughput benchmarks on $t\bar{t}$ events in the Open Data Detector, the RTX A6000 in FP32 outperforms the CPU in most pileup scenarios, while GPUs with lower FP32 throughput exceed the CPU only above pileup 200. In FP64, only the A30, with its 1:2 FP64-to-FP32 performance ratio, surpasses the CPU and only at high pileup.

Load-bearing premise

The load-bearing premise is that simulated detector material can be treated as if only muons pass through it; if pions and other hadrons interact with material differently, the measured tracking efficiency and the GPU-versus-CPU throughput comparison may not carry over to real HL-LHC events.

Editorial extensions

If this is right

  • If the central claim holds, GPU-resident reconstruction is a practical route for HL-LHC event rates, with FP32 sufficient for pattern finding and event throughput.
  • The nearly identical CKF patterns mean track finding can be offloaded to GPUs without changing downstream physics in most cases.
  • FP64 remains necessary for fitted track parameters at the current smoothing stage, implying mixed-precision pipelines until a stable smoother is integrated.
  • The weak scaling with multiple CUDA streams points to memory allocation rather than compute as the current bottleneck, so throughput gains are expected from allocator or service-model improvements.
  • Completion of ambiguity resolution and fake/duplicate track rejection is required before the physical performance can be fully assessed.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the muon-only material assumption is corrected, the relative GPU advantage could shrink on events with many hadronic interactions, because more complex and divergent track propagation tends to penalize lock-step GPU execution.
  • The 94.7% FP32 pattern match suggests that a two-stage precision strategy, FP32 for finding and FP64 for final fitting, could be a production design, something the paper does not itself propose.
  • Because the full chain now runs on-device with one-time geometry transfer, the same code could be applied to online trigger reconstruction, not just offline analysis, if latency and memory constraints are met.
  • The authors' throughput results are tied to current compilers and allocators; the trajectory of GPU tooling suggests the measured gaps may close or widen in ways that only re-benchmarking on future hardware can resolve.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. This paper reports the development status of traccc, a GPU-based track reconstruction library within the ACTS project. It describes a full chain (clustering, seeding, combinatorial Kalman filter, and Kalman-filter fitting with an RTS smoother) implemented in CUDA and SYCL, and benchmarks the library on Geant4-simulated ttbar events in the Open Data Detector geometry. The paper validates GPU results against a CPU baseline by comparing CKF track patterns and fitted track parameters in FP32 and FP64 (Table 1), shows a CPU-only tracking efficiency curve (Fig. 1), and measures event throughput for three NVIDIA GPUs versus an AMD EPYC CPU as a function of pileup and thread/stream count (Figs. 2 and 3). The central claims are that the physics performance of GPU and CPU are 'very close' and that GPUs achieve higher throughput than CPUs for sufficiently large events.

Significance. The library addresses a pressing HL-LHC computing problem, and the paper provides concrete, directly measured throughput numbers on multiple GPU architectures using a realistic detector geometry. The performance comparison is a direct measurement rather than a derived model result, and the open-source code availability supports reproducibility. However, the physics-validation component is currently incomplete: the FP32 fitted-parameter matching ratios are far from 'very close' at tight tolerances, and efficiency, fake-rate, and duplicate-rate metrics are not measured on the GPU. The throughput claim is thus more solid than the physics-equivalence claim, which needs either additional GPU-side measurements or substantial qualification.

major comments (4)
  1. [Abstract; Table 1; Sec. 5] The abstract and conclusions state that 'the physics performance for GPU and CPU are very close,' but the evidence in Table 1 does not support this for FP32: only 94.7% of CKF patterns match, and the fitted track parameters match CPU in only 37.8% of cases at 0.01% tolerance and 75.4% at 5% tolerance. Since the GPU throughput advantage is demonstrated mainly in FP32, this discrepancy directly affects the regime the paper promotes. The claim should be reformulated to distinguish pattern-level agreement from parameter-level agreement, and the abstract should note the fitted-parameter limitation or the claim should be supported by additional GPU-side validation.
  2. [Sec. 3.1; Fig. 1; Sec. 4] Tracking efficiency is measured only for the CPU implementation (Fig. 1), and Section 4 explicitly states that duplicate and fake rates have not been quantified and that no ambiguity resolution is present. The sentence in Section 3.1 that GPU efficiency 'may differ up to 5% according to Table 1' is not a rigorous bound: pattern identity at 94.7% does not translate directly into an efficiency difference bound, especially when the double-matching condition and unmeasured fake and duplicate rates are involved. The paper should either provide GPU efficiency, fake-rate, and duplicate-rate measurements or clearly restrict the physics-performance claim to CKF pattern identity for the configurations tested.
  3. [Sec. 3; Sec. 4] The material-interaction model assumes muon trajectories for all particle types in ttbar events (Section 3). Because the sample contains hadrons whose nuclear interactions differ substantially from muons, the absolute tracking efficiency and perhaps the degree of pattern divergence could be affected; the assumption is applied identically to CPU and GPU, so it does not invalidate the relative throughput comparison, but it limits the generality of the physics-performance claim for real HL-LHC data. A discussion of this limitation, or a validation with particle-dependent material effects, should be added.
  4. [Figs. 2-3; Sec. 3.2] The event-throughput curves are presented without error bars, run-to-run spread, or a statement on how many repetitions were used. This matters because several comparisons are close: in FP32 the RTX 2080 SUPER and A30 only exceed the CPU for pileup above 200, and in FP64 only the A30 does so at high pileup. The claim that GPUs outperform CPUs 'for sufficiently large events' would be strengthened by reporting measurement uncertainties and, ideally, by scanning the stream and thread counts in a way that does not rely on self-selected configurations. At minimum the absence of uncertainties should be acknowledged.
minor comments (4)
  1. [Table 1 caption] 'aloowed' should be 'allowed'.
  2. [Sec. 4] 'accross' should be 'across'.
  3. [Sec. 3.1] The number of events used for Table 1 and Fig. 1 is not stated; specifying it would help the reader interpret percentages such as 94.7% or 37.8%.
  4. [Reference [11]] The FastSV reference lacks venue and year information; a complete citation would be helpful.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: all performance and physics-comparison results are direct measurements against simulated truth or CPU baselines, with no fitted parameter renamed as a prediction.

full rationale

The paper's central claims are empirical benchmarks: GPU and CPU implementations of the same traccc algorithms are executed on the same simulated t-tbar events in the ODD geometry, and the outputs are compared directly. Table 1 reports measured matching ratios of CKF track patterns and fitted parameters between GPU and CPU; Figs. 2 and 3 report measured event throughput. No result is derived from a model fitted to the data it then claims to predict. The CPU-only tracking efficiency in Fig. 1 is stated explicitly as a CPU measurement, and the paper qualifies that GPU efficiency may differ by up to 5% according to Table 1; this is an acknowledged extrapolation, not a circular derivation. The material-interaction approximation ('assuming muon trajectories') is a shared simulation assumption applied identically to both CPU and GPU, so it does not smuggle in the conclusion. The references to prior work by the same authors, e.g. [5], [6], [18], and [26], support algorithmic components but are not invoked as the evidence for the physics-performance or throughput claims; those claims stand on the benchmark measurements reported in this paper. The acknowledged limitations — unquantified duplicate and fake rates, missing ambiguity resolution, and lower FP32 fitted-parameter matching due to RTS-smoother numerical instability — are explicitly stated in Sections 3.1 and 4, and they weaken the strength of the physics-performance conclusion but do not make it circular. Overall, the derivation chain is self-contained with respect to the claims made: measurements are measurements, and no fitted input is relabeled as a prediction.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new theoretical entities. Its central claims rest on benchmark configuration choices, simulation assumptions, and the fairness of the CPU baseline, all listed above.

free parameters (4)
  • Tolerated difference thresholds for parameter matching = [0.01%, 0.1%, 1%, 5%]
    Table 1 matching ratios are defined relative to these hand-chosen tolerances; lower tolerances dramatically reduce the reported GPU-CPU agreement, from 75.4% down to 37.8% in FP32.
  • Reconstructible particle selection cuts = pT > 500 MeV/c, |z| < 500 mm, r < 200 mm
    These cuts define the denominator of tracking efficiency in Section 3.1 and are arbitrary analysis choices.
  • Double matching thresholds = N > Nt/2 and N > Np/2
    Track-particle matching success is defined by these hand-picked thresholds, affecting the efficiency in Fig. 1.
  • CUDA stream count for GPU benchmark = 2 for RTX A6000 and A30, 1 for RTX 2080 SUPER
    Stream counts are chosen from Fig. 2 observations; the throughput comparison depends on this configuration.
assumptions (4)
  • domain assumption Geant4-simulated ttbar events in the ODD detector are representative of HL-LHC ATLAS ITk workloads.
    Section 3 uses ODD inspired by ATLAS ITk; no validation of this proxy is provided.
  • domain assumption Material interactions are modeled using muon trajectories for all particle types.
    Section 3 states this simplification; hadronic interactions are neglected, which may bias efficiency.
  • domain assumption The CPU implementation is a fair and non-degenerate baseline for comparison.
    Section 3.2 compares throughput directly to the CPU implementation with 48 threads; no independent baseline or validation of optimality is given.
  • standard math IEEE 754 floating point arithmetic is correctly implemented on the tested GPUs.
    Section 2 states FP32/FP64 according to IEEE 754; the nondeterminism of atomic operations is cited as a source of differences.

how reviews work

0 comments
Cite this review

Pith. "Pith review of traccc: GPU track reconstruction library for HEP experiments." pith.science (2026). https://pith.science/paper/XBVNJJSR

@misc{pith2026250522822,
  author       = {Pith},
  title        = {Pith review of: traccc: GPU track reconstruction library for HEP experiments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XBVNJJSR}},
  note         = {Machine review of arXiv:2505.22822}
}
read the original abstract

We present the current development status and progress of traccc, a GPU track reconstruction library developed in the context of the A Common Tracking Software (ACTS) project. traccc implements tracking algorithms used in high energy physics (HEP) experiments, including the Kalman filter based track finding and fitting. We benchmark the software with data simulated by Geant4 to measure the physics and computing performance. We show that the physics performance for GPU and CPU are very close. We also show that the GPUs can achieve higher computational performance than the CPU for sufficiently large events.

Figures

Figures reproduced from arXiv: 2505.22822 by the authors.

Figure 1
Figure 1. Tracking efficiency of the CPU implementation as a function of η for a tt¯ collision event in the ODD geometry. The event is simulated with 140 pileup and the FP32 precision is used [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Event throughput measured with the RTX A6000 (GPU) and AMD EPYC 7413 (CPU) as a function of the number of CPU threads. tt¯ collision events with 140 pileup are reconstructed using FP32 precision. The dotted line represents ideal linear scaling of CPU throughput with increasing thread count. The event throughput of GPUs and CPUs as a function of tt¯ pileup is presented in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Event throughput as a function of tt¯ pileup for FP32 (left) and FP64 (right) precision. The bottom plots show the ratio of GPU to CPU event throughput. 4 Discussion While the current track finding algorithm demonstrates good tracking efficiency, a complete understanding of its physical performance requires investigation of duplicate and fake track rates. Duplicate tracks arise when multiple tracks share the same or… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

26 extracted references · 15 canonical work pages

  1. [1]

    ATLAS Collaboration, ATLAS Software and Computing HL-LHC Roadmap (2022), https://cds.cern.ch/record/2802918

    arXiv 2022

  2. [2]

    Dennard et al., Design of ion-implanted MOSFET’s with very small physical dimensions, IEEE Journal of Solid-State Circuits 9, 256 (1974)

    R. Dennard et al., Design of ion-implanted MOSFET’s with very small physical dimensions, IEEE Journal of Solid-State Circuits 9, 256 (1974). https://doi.org/10.1109/JSSC.1974.1050511

    arXiv 1974

  3. [3]

    Yeo et al., Github repository of acts-project /traccc, https://github.com/ acts-project/traccc

    B. Yeo et al., Github repository of acts-project /traccc, https://github.com/ acts-project/traccc

    work page

  4. [4]

    Ai et al., A Common Tracking Software Project, Comput

    X. Ai et al., A Common Tracking Software Project, Comput. Softw. Big Sci.6, 8 (2022). https://doi.org/10.1007/s41781-021-00078-8

    doi:10.1007/s41781-021-00078-8 2022

  5. [5]

    Gessinger et al., ACTS GPU Track Reconstruction Demonstrator for HEP, Proceed- ings of the CTD 2022 pp

    P. Gessinger et al., ACTS GPU Track Reconstruction Demonstrator for HEP, Proceed- ings of the CTD 2022 pp. 46–53 (2023). https://doi.org/10.5281/zenodo.8119864

    work page doi:10.5281/zenodo.8119864 2023

  6. [6]

    A. Krasznahorkay et al., traccc - a close to single-source track reconstruction demonstra- tor for CPU and GPU, https://indico.jlab.org/event/459/contributions/ 11420/, presented at the 26th International Conference on Computing in High Energy and Nuclear Physics

    work page

  7. [7]

    Kalman, A New Approach to Linear Filtering and Prediction Problems, Journal of Basic Engineering 82, 35 (1960)

    R.E. Kalman, A New Approach to Linear Filtering and Prediction Problems, Journal of Basic Engineering 82, 35 (1960). https://doi.org/10.1115/1.3662552

    doi:10.1115/1.3662552 1960

  8. [8]

    Frühwirth, Application of Kalman filtering to track and vertex fitting, Nucl

    R. Frühwirth, Application of Kalman filtering to track and vertex fitting, Nucl. Instr. and Meth. A 262, 444 (1987). https://doi.org/10.1016/0168-9002(87)90887-4

    doi:10.1016/0168-9002(87)90887-4 1987

Show all 26 references
  1. [9]

    Agostinelli et al., Geant4—a simulation toolkit, Nucl

    S. Agostinelli et al., Geant4—a simulation toolkit, Nucl. Instr. and Meth. A 506, 250 (2003). https://doi.org/10.1016/S0168-9002(03)01368-8

    2003 doi

  2. [10]

    Gessinger-Befurt, A

    P. Gessinger-Befurt, A. Salzburger, J. Niermann, The Open Data Detector Track- ing System, Journal of Physics: Conference Series 2438, 012110 (2023). https://doi.org/10.1088/1742-6596/2438/1/012110

    2023 doi

  3. [11]

    Zhang, A

    Y . Zhang, A. Azad, Z. Hu, FastSV: A Distributed-Memory Connected Component Al- gorithm with Fast Convergence (2020), pp. 46–57

    2020

  4. [12]

    Billoir, Progressive track recognition with a Kalman-like fitting procedure, Computer Physics Communications 57, 390 (1989)

    P. Billoir, Progressive track recognition with a Kalman-like fitting procedure, Computer Physics Communications 57, 390 (1989). https://doi.org/10.1016/0010-4655(89)90249- X

    1989 doi

  5. [13]

    Billoir, S

    P. Billoir, S. Qian, Simultaneous pattern recognition and track fitting by the Kalman fil- tering method, Nucl. Instr. and Meth. A 294, 219 (1990). https://doi.org/10.1016/0168- 9002(90)91835-Y

    1990 doi

  6. [14]

    Nyström, Über die numerische Integration von Di fferentialgleichungen, Acta Soci- etatis scientiarum Fennicae (Druck der Finnischen literaturgesellschaft, 1925)

    E. Nyström, Über die numerische Integration von Di fferentialgleichungen, Acta Soci- etatis scientiarum Fennicae (Druck der Finnischen literaturgesellschaft, 1925)

    1925

  7. [15]

    Bugge, J

    L. Bugge, J. Myrheim, Tracking and track fitting, Nuclear Instruments and Methods 179, 365 (1981). https://doi.org/10.1016/0029-554X(81)90063-X

    1981 doi

  8. [16]

    E. Lund, L. Bugge, I. Gavrilenko, A. Strandlie, Track parameter propagation through the application of a new adaptive Runge-Kutta-Nyström method in the ATLAS experiment, JINST 4, P04001 (2009). https://doi.org/10.1088/1748-0221/4/04/P04001

    2009 doi

  9. [17]

    E. Lund, L. Bugge, I. Gavrilenko, A. Strandlie, Transport of covariance matrices in the inhomogeneous magnetic field of the ATLAS experiment by the application of a semi-analytical method, JINST 4, P04016 (2009). https: //doi.org/10.1088/1748- 0221/4/04/P04016

    2009 doi

  10. [18]

    B. Yeo, H. Gray, A. Salzburger, S.N. Swatman, The derivation of Jacobian ma- trices for the propagation of track parameter uncertainties in the presence of mag- netic fields and detector material, Nucl. Instr. and Meth. A 1068, 169734 (2024). https://doi.org/10.1016/j.nima.2024.169734

    2024

  11. [19]

    Rauch, F

    H.E. Rauch, F. Tung, C.T. Striebel, Maximum likelihood estimates of linear dynamic systems, AIAA Journal 3, 1445 (1965). https://doi.org/10.2514/3.3166

    1965 doi

  12. [20]

    Reyes, V

    R. Reyes, V . Lomüller, SYCL: Single-source C ++ accelerator programming, in Inter- national Conference on Parallel Computing (2015)

    2015

  13. [21]

    Gonella, The ATLAS ITk detector system for the Phase-II LHC upgrade, Nucl

    L. Gonella, The ATLAS ITk detector system for the Phase-II LHC upgrade, Nucl. Instr. and Meth. A 1045, 167597 (2023). https://doi.org/10.1016/j.nima.2022.167597

    2023

  14. [22]

    Frühwirth et al., Data analysis techniques for high-energy physics; 2nd ed., Cam- bridge monographs on particle physics, nuclear physics, and cosmology (Cambridge Univ

    R. Frühwirth et al., Data analysis techniques for high-energy physics; 2nd ed., Cam- bridge monographs on particle physics, nuclear physics, and cosmology (Cambridge Univ. Press, Cambridge, 2000)

    2000

  15. [23]

    Frühwirth, A

    R. Frühwirth, A. Strandlie, Pattern Recognition, Tracking and Vertex Reconstruction in Particle Detectors (Springer Cham, 2021)

    2021

  16. [24]

    Fraser, Ph.D

    D.C. Fraser, Ph.D. thesis, Massachusetts Institute of Technology (1967), http://hdl. handle.net/1721.1/13543

    1967

  17. [25]

    NVIDIA Corporation, Triton inference server: An optimized cloud and edge inferenc- ing solution, https://github.com/triton-inference-server

  18. [26]

    Swatman, A.L

    S.N. Swatman, A.L. Varbanescu, A. Krasznahorkay, A. Pimentel, Modelling Perfor- mance Loss due to Thread Imbalance in Stochastic Variable-Length SIMT Workloads, in 2022 30th International Symposium on Modeling, Analysis, and Simulation of Com- puter and Telecommunication Syste...

    2022

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.