Pith. sign in

REVIEW 2 major objections 6 minor 7 cited by

Data-parallel leading-order event generation in MadGraph5_aMC@NLO

T0 review · 2 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read A MadGraph5_aMC@NLO plugin rewrites leading-order helicity amplitudes as data-parallel templated C++ and CUDA, scaling speed-up linearly with SIMD register width and giving order-of-magnitude GPU gains for high-multiplicity QCD processes.

desk verdict Serious engineering contribution with credible speed-ups, but the missing Fortran-level physics check is a real gap the authors should close before calling this production. read the letter →

arxiv 2507.21039 v2 pith:X7DPXCKS submitted 2025-07-28 hep-ph hep-exphysics.comp-ph

Stephan Hageböck , Daniele Massaro , Olivier Mattelaer , Stefan Roiser , Andrea Valassi , Zenny Wettersten This is my paper
classification hep-phhep-exphysics.comp-ph PACS 02.70.Uu07.05.Tp
keywords CUDACPPMadGraph5_aMC@NLOleading-ordereventgenerationhelicityamplitudesSIMDvectorisationGPUoffloadingmixedprecision
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

The paper claims that leading-order Monte Carlo event generation in MadGraph5_aMC@NLO can be substantially accelerated by replacing the program's Fortran helicity-amplitude routines with data-parallel ones generated by a new plugin, CUDACPP. Because a leading-order amplitude is the same branch-free formula at every phase-space point, many events can be pushed through the same wavefunction and vertex calls in lockstep: throughput on CPUs grows linearly with SIMD register width and thread count, and GPU evaluation goes beyond SIMD. In full event generation the observed speed-ups match Amdahl's law computed from measured amplitude runtime fractions, and for high-multiplicity QCD processes, where amplitudes are 96.7 to 99.6 percent of executable runtime, GPU offloading beats a well-utilised server CPU by an order of magnitude. A mixed-precision mode, kinematics in double precision and colour algebra in single precision, stays near the double-precision baseline in accuracy while adding throughput. This matters because those multi-jet QCD samples are exactly the processes expected to dominate event-generation computing cost in the HL-LHC era.

What carries the argument

The object that carries the argument is the CUDACPP-generated amplitude routine set: a one-to-one port of the MG5AMC Fortran wavefunction and vertex code in which all floating-point numbers become a compile-time \texttt{FPTYPE} and all event-level arrays gain an extra dimension of size $\texttt{VECSIZE}$, so one call evaluates many phase-space points in lockstep. A \texttt{Kernel} class hides the memory-access differences between the SIMD CPU and SIMT GPU backends, and a small \texttt{Bridge}/\texttt{fBridge} interface lets the unmodified Fortran MadEvent program construct, launch, and destroy these kernels. Around this core sit two supporting mechanisms: the multi-event interface, now in upstream MG5AMC since version 3.6.0, which makes event data contiguous and vectorisable, and the new gridpack flags \texttt{-p} (number of simultaneous executions) and \texttt{-m} (maximum events per job), which are what allow a GPU to be kept busy across many integration channels. The mixed-precision mode, evaluating helicity amplitudes in FP64 but colour algebra in FP32, is the paper's default and is justified by the integer-valued colour matrix structure.

What would settle it

Run the default Fortran gridpack and the CUDACPP gridpack for the same process (e.g. $pp\to t\bar{t}+3j$) with identical run cards and random seeds, generate the same number of unweighted events, and compare the total cross sections and a set of differential distributions (jet $p_T$, invariant masses, rapidities) with enough statistics to resolve per-mille differences; any significant disagreement would mean the port changes the physics. A cheaper partial check is a direct Fortran-versus-CUDACPP comparison of squared amplitudes on identical phase-space points, which the paper does not report, since its precision study compares CUDACPP precision modes against each other.

Watch

Extended reading notes

Core claim

The central claim, stated on the paper's own terms, is that CUDACPP makes MadGraph5_aMC@NLO leading-order event generation data-parallel by porting the helicity-amplitude code one-to-one from ALOHA-generated Fortran into templated C++ and CUDA, with every floating-point type abstracted so the same source compiles to scalar, SSE4, AVX2, AVX-512 (in 256-bit and 512-bit register modes), CUDA, and HIP backends. Standalone amplitude throughput then scales linearly with SIMD register size and with the number of threads, and on a GPU exceeds the CPU results. In real gridpack event generation, the speed-up is bounded by the fraction of runtime spent in amplitude routines, exactly as Amdahl's law predicts: for $gg\to t\bar{t}+ng$ with $n=2$ or $3$, amplitudes make up 96.7 to 99.6 percent of the Fortran executable's runtime and the measured acceleration is correspondingly large, while for simple Drell-Yan processes it is modest. The paper further claims that proper GPU utilisation, made possible by the new gridpack flags that schedule work across integration channels, yields an order-of-magnitude gain over the best CPU configuration for high-multiplicity QCD, with the single-channel process $gg\to t\bar{t}+3g$ at least $\sim 500$ times faster than single-core Fortran. Finally, it demonstrates through CADNA measurements and eight-million-point comparisons that a mixed FP64/FP32 mode, with kinematics in double precision and colour algebra in single precision, is numerically safe, whereas full FP32 is flagged as likely to be problematic and left for case-by-case validation.

Load-bearing premise

The speed-up claims assume the CUDACPP amplitude code is a numerically faithful one-to-one port of the reference Fortran routines; the paper checks the precision of the amplitudes themselves but never compares CUDACPP-generated unweighted events against Fortran events for cross sections or differential distributions, so a subtle porting error would make every timing gain meaningless.

Editorial extensions

If this is right

  • High-multiplicity leading-order QCD samples, the dominant event-generation cost at the HL-LHC, can be produced about an order of magnitude faster on GPU nodes than on optimally used server CPUs, and at least $\sim 500$ times faster than single-core Fortran for $gg\to t\bar{t}+3g$.
  • On CPU-only hardware, the same gridpacks compiled for AVX2 or AVX-512 recover much of the gain, with the acceleration tracking the amplitude runtime fraction exactly as Amdahl's law predicts.
  • Scattering amplitudes stop being the bottleneck of LO event generation: the GPU profile shows the amplitude kernel at roughly 1.6 percent of runtime where Fortran's amplitude routine took 88 to 97 percent, shifting the remaining cost to host-device latency and sequential MadEvent code.
  • The mixed FP64/FP32 colour-algebra mode gives a further GPU throughput gain of about 22 percent for colour-heavy processes such as $gg\to t\bar{t}+3g$ while staying within casting loss of the FP64 baseline.
  • The multi-event interface and parallel gridpack flags are now part of upstream MadGraph5_aMC@NLO (versions 3.6.0 and 3.6.2), so the parallelism groundwork benefits users beyond CUDACPP.

Reading between the lines

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

  • A direct test the paper leaves implicit: for any process with measured amplitude fraction $p$, the event-generation speed-up on a backend with $n$-wide parallelism should equal $1/[1-p(1-1/n)]$; sweeping processes and instruction sets would confirm or break this scaling law.
  • Because CUDACPP does not yet support helicity recycling, which the paper says can more than double speed for processes with many external vector bosons, the quoted gaps over the Fortran baseline may shrink once that feature lands, since the comparisons here exclude it explicitly.
  • The same data-parallel treatment is pointed at NLO tree-level amplitudes and loop libraries as ongoing work; the paper's own logic implies the interesting question is whether the factor-of-ten GPU gain survives beyond leading order, where the amplitude structure and phase-space treatment differ.
  • On GPUs, the paper's FlameGraph shows host-device bridge routines at 35.5 percent of runtime, suggesting that combining CUDACPP with on-device phase-space sampling or PDF evaluation, both cited as being developed elsewhere, is the most direct route to extending the speed-up to simpler processes.
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

2 major / 6 minor

Summary. The manuscript presents CUDACPP, a plugin for MadGraph5_aMC@NLO that generates data-parallel helicity amplitudes in templated C++/CUDA and integrates them into MadEvent through a multi-event interface and modified gridpack driver flags (-p, -m). Standalone benchmarks on two Intel Xeon CPUs show throughput scaling with SIMD width and thread count, and A100 benchmarks show additional GPU speed-up for high-multiplicity processes. Event-generation benchmarks compare wall-clock runtimes for Fortran, SIMD, and CUDA backends for Drell-Yan and ttbar+jets processes, reporting up to order-of-magnitude GPU gains for gg->tt+3g in the many-events limit. A numerical-precision study using CADNA and FP64-baseline comparisons supports a mixed FP64/FP32 mode as the default.

Significance. The paper addresses a real and quantified need: HL-LHC Monte Carlo generation is projected to consume a substantial fraction of HL-LHC CPU resources. CUDACPP is integrated into upstream MG5aMC, is publicly available, and the benchmark methodology is careful: each point is a mean over five or ten runs with standard deviations, on exclusive nodes, with explicit hardware details. The standalone throughput results cleanly demonstrate the intended data-parallel speed-ups, and the Amdahl-style analysis correctly identifies that the speed-up in full event generation is bounded by the amplitude fraction. If the missing physics validation is supplied, the paper would constitute a useful, reproducible engineering result with immediate practical impact for high-multiplicity LO samples.

major comments (2)
  1. [3.1; 4.1; 5.2-5.3] Section 3.1 asserts that the CUDACPP amplitude code is a "one-to-one port" of the ALOHA Fortran, but the paper never validates this equivalence at the level that matters for the central claim. Section 4.1 validates numerical precision only within CUDACPP: Table 1 and Figs. 3-4 take CUDACPP FP64 evaluations as the baseline and compare FP32 and mixed modes to it; no comparison to the ALOHA-generated Fortran amplitudes at identical phase-space points is reported. Sections 5.2 and 5.3 compare only wall-clock runtimes and never compare cross sections, acceptances, or differential distributions of the produced unweighted events. Since the code snippets in Section 3.1 show structural differences (an extra sign argument, the COUPs array, templated memory access), a subtle sign, coupling-ordering, or array-layout error would leave every runtime number unchanged while invalidating the physics of all generated samples. I request a direct event-level validation, e.g. identical seeds and grids for Fortran and CUDACPP with comparisons of integrated cross sections and representative differential distributions, or at minimum an amplitude-level comparison at fixed phase-space points.
  2. [3.2] The block-wise Monte Carlo over n events changes the sampling algorithm relative to the scalar Fortran generator: all n events in a block share the same phase-space mapping branch and are generated before the MC choice is advanced. The only condition given for absence of bias is the qualitative statement that n must be much smaller than the number of evaluated phase-space points. No empirical or analytic check is reported for the default values n=16 (SIMD) and n=32 (GPU), and the event-level validation missing in the previous comment would be the natural place to test this. Please add an explicit unbiasedness test, for example a distribution-level comparison of weighted or unweighted events for several values of n.
minor comments (6)
  1. [Abstract] The abstract contains a duplicated word: "routines routines"; please fix.
  2. [Abstract; 5.1] The word "predictions" overstates the status of the Amdahl comparison, since the fractions p in Table 2 are measured on the same processes and configurations whose speed-ups are then reported in Sections 5.2 and 5.3; suggest phrasing such as "consistent with Amdahl expectations from measured runtime fractions".
  3. [5.3] The "minimum" 512x and 64x speed-up figures in the final paragraph of Section 5.3 are estimates obtained by multiplying a lower bound from n=2 processes by speed-up ratios from Fig. 21; please state explicitly that these are not directly measured and consider reporting a directly measured Fortran runtime for gg->tt+3g.
  4. [4.1] The statement that "some small non-conclusive tests suggest rounding errors will 'wash out'" is anecdotal; either remove it or replace it with the actual test, since FP32 is a user-selectable option.
  5. [2.1; Ref. 41] Figure 1 contains the typo "INTRUCTIONS", and reference [41] contains "Intel Cerporation"; please correct both.
  6. [5.2; 6] The Fortran baseline is run without helicity recycling and without the default MG5aMC parton grouping; this is disclosed in Section 5.2, but it should be restated in the conclusion where speed-ups are summarized so that readers do not interpret them as speed-ups over default MG5aMC settings.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: speed-up claims are direct measurements, and the Amdahl cross-check is a parameter-free consistency test.

full rationale

All of the paper's headline speed-ups are direct wall-clock or throughput measurements of independently compiled backends (Fortran, scalar C++, SSE4/AVX2/AVX-512, CUDA) on the same processes and hardware; they are not derived from the quantities they claim to measure. The only 'prediction' in the paper is the Amdahl forecast of Section 5.1, built from separately profiled Fortran runtime fractions (Table 2) inserted into Eq. (2), and then compared with the measured event-generation speed-ups of Sections 5.2-5.3. Because the fraction p is measured from the baseline Fortran executable rather than fitted to the CUDACPP speed-up data, and because Eq. (2) has no remaining free parameters, the agreement is a genuine consistency check: a poorly parallelised amplitude routine would fall below the bound. This is not an equation reducing to its own input. The 'one-to-one port' statement in Section 3.1 is an unverified structural claim, and the absence of a direct CUDACPP-vs-Fortran event-level cross-section comparison is an important validation gap, but that is a correctness risk rather than circularity: a porting error would invalidate the physics, not make the speed-up definitionally equal to its input. Self-citations [28-32] are prior engineering reports; the benchmark numbers reported here are new measurements and do not rely on those references for their values. The mixed-precision default is justified by internal CADNA and FP64-baseline tests, which are again self-contained numerical checks. No circular step meets the quoted-evidence threshold.

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

The central performance conclusions rest on a few unvalidated assumptions: the block-wise Monte Carlo over n events is unbiased, the one-to-one port preserves physics, and the Amdahl predictions use runtime fractions measured from the same processes. No fitted constants are hidden in the benchmarks, though several user-tuned parameters (vector_size, nb_warp, -p, -m) shape the results.

free parameters (4)
  • vector_size (block size n) = 16 (SIMD), 32 (GPU default)
    Chosen as the number of events evaluated in lockstep; affects MC bias and SIMD/SIMT utilization.
  • nb_warp = 1 (SIMD), 512 (GPU default)
    Number of warps scheduled per kernel launch; determines GPU grid size and throughput.
  • gridpack parallel workers (-p) = 8 in main GPU and AVX2 comparisons; default 1
    Number of simultaneous MadEvent executions; the order-of-magnitude GPU claim uses -p 8 for CPUs and GPUs.
  • gridpack max events per job (-m) = 1000 in Fig. 21; default 2500
    Limits events per MadEvent execution; affects scheduling overhead and GPU utilization.
assumptions (4)
  • standard math Amdahl's law bounds speed-up using the measured runtime fraction p spent in helicity amplitudes.
    Used in Eq. (2) and Fig. 12 to predict event generation speed-up from standalone amplitude speed-ups; p is taken from Table 2.
  • ad hoc to paper Block-wise Monte Carlo over n events does not bias unweighted event distributions for n much smaller than the number of phase-space points.
    Stated in Section 3.2 without empirical validation; the entire SIMD and SIMT lockstep scheme relies on this to avoid altering physics results.
  • domain assumption The CUDACPP C++ and CUDA amplitude code is a one-to-one port of the Fortran reference, preserving numerical results.
    Section 3.1 asserts the port, but no comparison of generated cross sections or distributions against Fortran is shown.
  • domain assumption Runtime fractions p measured by FlameGraphs from sequential Fortran runs remain representative when amplitudes are parallelized.
    Used to compare measured speed-ups to Amdahl predictions; assumes parallelization does not change the sequential fraction structure.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Data-parallel leading-order event generation in MadGraph5_aMC@NLO." pith.science (2026). https://pith.science/paper/X7DPXCKS

@misc{pith2026250721039,
  author       = {Pith},
  title        = {Pith review of: Data-parallel leading-order event generation in MadGraph5_aMC@NLO},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X7DPXCKS}},
  note         = {Machine review of arXiv:2507.21039}
}
read the original abstract

The CUDACPP plugin for MadGraph5_aMC@NLO aims to accelerate leading order tree-level event generation by providing the MadEvent event generator with data-parallel helicity amplitudes. These amplitudes are written in templated C++ and CUDA, allowing them to be compiled for CPUs supporting SSE4, AVX2, and AVX-512 instruction sets as well as CUDA- and HIP-enabled GPUs. Using SIMD instruction sets, CUDACPP-generated amplitude routines routines are shown to speed up linearly with SIMD register size, and GPU offloading is shown to provide acceleration beyond that of SIMD instructions. Additionally, the resulting speed-up in event generation perfectly aligns with predictions from measured runtime fractions spent in amplitude routines, and proper GPU utilisation can speed up high-multiplicity QCD processes by an order of magnitude when compared to optimal CPU usage in server-grade CPUs.

Figures

Figures reproduced from arXiv: 2507.21039 by the authors.

Figure 1
Figure 1. Simple illustration of the difference between SISD (left) and SIMD (right) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Simple illustration of the difference between SISD (left) and SIMT (right) [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Relative difference in scattering amplitudes squared evaluated in FP32 [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figures from the paper (19 more)
Figure 4
Figure 4. Figure 4: Relative difference in scattering amplitudes squared evaluated in FP32 [PITH_FULL_IMAGE:figures/full_fig_p013_4.png]
Figure 5
Figure 5. Figure 5: CUDACPP standalone throughput (including random number genera￾tion, phase-space mapping, and scattering amplitudes) for the SM Drell-Yan process uu → e +e −+3g (left) and QCD process g g → tt+2g (right) for varying SIMD instruc￾tion sets, varying the number of threads …
Figure 6
Figure 6. Figure 6: CUDACPP standalone throughput (including random number genera￾tion, phase-space mapping, and scattering amplitudes) for the SM Drell-Yan process uu → e +e −+3g (left) and QCD process g g → tt+2g (right) for varying SIMD instruc￾tion sets, varying the number of threads …
Figure 7
Figure 7. Figure 7: CUDACPP standalone throughput (including random number genera￾tion, phase-space mapping, and scattering amplitudes) for the SM Drell-Yan process uu → e +e − g g g (left) and QCD process g g → tt g g (right) for varying SIMD in￾struction sets, varying the number of simu…
Figure 8
Figure 8. Figure 8: CUDACPP standalone throughput (including random number genera￾tion, phase-space mapping, and scattering amplitudes) for the SM Drell-Yan process uu → e +e − + 3g (left) and QCD process g g → tt + 2g (right) for varying SIMD instruction sets, varying the number of simul…
Figure 9
Figure 9. Figure 9: CUDACPP standalone throughput (including random number genera￾tion, phase-space mapping, and scattering amplitudes) for the SM Drell-Yan process uu → e +e − plus n ∈ [0, 4] gluon jets with differing floating point types running on an Nvidia A100 GPU, as well as compari…
Figure 10
Figure 10. Figure 10: CUDACPP standalone throughput (including random number generation, phase-space mapping, and scattering amplitudes) for the SM QCD process g g → tt plus n ∈ [0, 3] gluon jets with differing floating point types running on an Nvidia A100 GPU, as well as comparison with …
Figure 11
Figure 11. Figure 11: FlameGraph [46] of Fortran MADEVENT event generation for the process g g → tt g g without helicity recycling [13], generating 10 000 unweighted events. The subroutine smatrix1, which wraps helicity amplitude evaluations, has been highlighted. The x-axis displays runti…
Figure 12
Figure 12. Figure 12: Expected Amdahlian speed-up in MADEVENT event generation from data￾parallel helicity amplitudes as a function of the number of simultaneous instructions for processes e +e − → µ +µ −, uu → e +e −, and g g → tt, plus n additional final state photons, gluons, and gluons…
Figure 13
Figure 13. Figure 13: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p023_13.png]
Figure 14
Figure 14. Figure 14: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p024_14.png]
Figure 15
Figure 15. Figure 15: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p025_15.png]
Figure 16
Figure 16. Figure 16: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p026_16.png]
Figure 17
Figure 17. Figure 17: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p027_17.png]
Figure 18
Figure 18. Figure 18: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p028_18.png]
Figure 19
Figure 19. Figure 19: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p029_19.png]
Figure 20
Figure 20. Figure 20: Total runtime to generate unweighted events for the process [PITH_FULL_IMAGE:figures/full_fig_p030_20.png]
Figure 21
Figure 21. Figure 21: Total runtime to generate unweighted events for the single- and multi [PITH_FULL_IMAGE:figures/full_fig_p031_21.png]
Figure 22
Figure 22. Figure 22: FlameGraph [46] of CUDACPP event generation with GPU offloading on an Nvidia A100 for the process g g → tt g g, generating 10 000 unweighted events. Compare to [PITH_FULL_IMAGE:figures/full_fig_p032_22.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 7 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Scattering Amplitudes as Programs: Self-Evolving Search for Theory and Event Generation

    hep-ph 2026-07 accept novelty 7.0 of 10

    Self-evolving program search over scattering amplitudes discovers known and hybrid evaluation structures, cutting counted arithmetic ~48x and reaching within ~14x of optimized MadGraph at n=6 while beating the tested ...

  2. An NLO-Matched Initial and Final State Parton Shower on a GPU

    hep-ph 2025-11 unverdicted novelty 6.0 of 10

    GAPS v2 is a GPU-accelerated parton shower for initial and final state emissions with NLO matching that achieves speed and energy performance on par with a 96-core CPU cluster for NLO Z production at the LHC.

  3. FPGA Acceleration of Matrix-Element Calculations for Monte Carlo Event Generation

    hep-ex 2026-05 unverdicted novelty 5.0 of 10

    FPGA implementations for full matrix-element workflow on e+e- to mu+mu- and color-algebra kernels on gg to ttbar+X achieve speedups and energy gains over CPU/GPU while preserving numerical accuracy.

  4. An NLO-Matched Initial and Final State Parton Shower on a GPU

    hep-ph 2025-11 conditional novelty 5.0 of 10

    GPU port of an NLO-matched parton shower achieves performance parity with a 96-core CPU cluster for LHC Z production simulations.

  5. Open LHC Monte Carlo Event Generation

    hep-ph 2026-05 unverdicted novelty 2.0 of 10

    A review of initiatives to make LHC Monte Carlo event generations available as open data to minimize redundant simulations and resource use.

  6. The Monte Carlo Ecosystem in High-Energy Physics: A Primer

    hep-ph 2026-05 accept novelty 1.0 of 10

    A primer by six leading developers maps the full Monte Carlo chain (matrix elements, parton showers, hadronisation, detector simulation, tuning, analysis) and the computing and reproducibility issues that come with it.

  7. The Monte Carlo Ecosystem in High-Energy Physics: A Primer

    hep-ph 2026-05 unverdicted

    A primer that surveys the architecture, methodologies, computational challenges, and future trajectory of the Monte Carlo event generator ecosystem in collider physics.

Reference graph

Works this paper leans on

59 extracted references · 30 canonical work pages · cited by 5 Pith papers

  1. [1]

    Schmidt, The High-Luminosity upgrade of the LHC: Physics and Technology Challenges for the Accelerator and the Experiments, Journal of Physics: Conference Series 706 (apr,

    B. Schmidt, The High-Luminosity upgrade of the LHC: Physics and Technology Challenges for the Accelerator and the Experiments, Journal of Physics: Conference Series 706 (apr,

    work page

  2. [2]

    3" (2019)

    HEP Software Foundation, J. Albrecht et al., A Roadmap for HEP Software and Computing R&D for the 2020s, Comput. Softw. Big Sci. "3" (2019) "1", 7, arXiv:1712.06982 [physics.comp-ph]

    arXiv 2019

  3. [3]

    J. Allison et al., Recent developments in geant4, Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment 835 (2016) 186

    work page 2016

  4. [4]

    ATLAS Software and Computing HL-LHC Roadmap

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

    arXiv 2022

  5. [5]

    CMS Phase-2 Computing Model: Update Document

    CMS Offline Software and Computing, “CMS Phase-2 Computing Model: Update Document.” https://cds.cern.ch/record/2815292, 2022

    work page arXiv 2022

  6. [6]

    Valassi, E

    HSF Physics Event Generator WG, A. Valassi, E. Yazgan, J. McFayden,et al., Challenges in Monte Carlo Event Generator Software for High-Luminosity LHC, Comput. Softw. Big Sci. 5 (2021) 1, 12, arXiv:2004.13687 [hep-ph]

    arXiv 2021

  7. [7]

    Buckley et al., General-purpose event generators for LHC physics, Phys

    A. Buckley et al., General-purpose event generators for LHC physics, Phys. Rept. 504 (2011) 145, arXiv:1101.2599 [hep-ph]

    arXiv 2011

  8. [8]

    Status and developments of event generators

    T . Sjöstrand,Status and developments of event generators, PoS LHCP2016 (2016) 007, arXiv:1608.06425 [hep-ph]

    work page Pith review arXiv 2016

Show all 59 references
  1. [9]

    J. M. Campbell et al., Event Generators for High-Energy Physics Experiments, in Snowmass 2021. 3, 2022. arXiv:2203.11110 [hep-ph]

    2021 arXiv

  2. [10]

    Frederix, S

    R. Frederix, S. Frixione, S. Prestel, and P . Torrielli,On the reduction of negative weights in MC@NLO-type matching procedures, JHEP 07 (2020) 238, arXiv:2002.12716 [hep-ph]

    2020 arXiv

  3. [11]

    J. R. Andersen and A. Maier, Unbiased elimination of negative weights in Monte Carlo samples, Eur. Phys. J. C 82 (2022) 5, 433, arXiv:2109.07851 [hep-ph]

    2022 arXiv

  4. [12]

    Frederix and P

    R. Frederix and P . Torrielli,A new way of reducing negative weights in MC@NLO, Eur. Phys. J. C 83 (2023) 11, 1051, arXiv:2310.04160 [hep-ph]

    2023 arXiv

  5. [13]

    Mattelaer and K

    O. Mattelaer and K. Ostrolenk, Speeding up MadGraph5_aMC@NLO, Eur. Phys. J. C 81 (2021) 5, 435, arXiv:2102.00773 [hep-ph]

    2021 arXiv

  6. [14]

    Lifson and O

    A. Lifson and O. Mattelaer,Improving colour computations in MadGraph5_aMC@NLO and exploring a 1/Nc expansion, Eur. Phys. J. C 82 (2022) 12, 1144, arXiv:2210.07267 [hep-ph]

    2022 arXiv

  7. [15]

    Hagiwara, J

    K. Hagiwara, J. Kanzaki, and K. Mawatari, QED and QCD helicity amplitudes in parton-shower gauge, Eur. Phys. J. C 80 (2020) 6, 584, arXiv:2003.03003 [hep-ph]

    2020 arXiv

  8. [16]

    J. Chen, K. Hagiwara, J. Kanzaki, and K. Mawatari, Helicity amplitudes without gauge cancellation for electroweak processes, Eur. Phys. J. C 83 (2023) 10, 922, arXiv:2203.10440 [hep-ph]. [Erratum: Eur.Phys.J.C 84, 97 (2024)]. 37 SciPost Physics Submission

    2023 arXiv

  9. [17]

    J. Chen, K. Hagiwara, J. Kanzaki, K. Mawatari, and Y.-J. Zheng, Helicity amplitudes in light-cone and Feynman-diagram gauges, Eur. Phys. J. Plus 139 (2024) 4, 332, arXiv:2211.14562 [hep-ph]

    2024 arXiv

  10. [18]

    Hagiwara, J

    K. Hagiwara, J. Kanzaki, O. Mattelaer, K. Mawatari, and Y.-J. Zheng,Automatic generation of helicity amplitudes in the Feynman-diagram gauge, Phys. Rev. D110 (2024) 5, 056024, arXiv:2405.01256 [hep-ph]

    2024 arXiv

  11. [19]

    Lifson, M

    A. Lifson, M. Sjodahl, and Z. Wettersten, Automating scattering amplitudes with chirality flow, Eur. Phys. J. C 82 (2022) 6, 535, arXiv:2203.13618 [hep-ph]

    2022 arXiv

  12. [20]

    Boman, A

    E. Boman, A. Lifson, M. Sjodahl, A. Warnerbring, and Z. Wettersten,Simplifying QCD event generation with chirality flow, reference vectors and spin directions, JHEP 02 (2024) 005, arXiv:2312.07447 [hep-ph]

    2024 arXiv

  13. [21]

    Kanzaki, Monte Carlo integration on GPU, Eur

    J. Kanzaki, Monte Carlo integration on GPU, Eur. Phys. J. C 71 (2011) 1559, arXiv:1010.2107 [physics.comp-ph]

    2011 arXiv

  14. [22]

    Hagiwara, J

    K. Hagiwara, J. Kanzaki, N. Okamura, D. Rainwater, and T . Stelzer,Fast calculation of HELAS amplitudes using graphics processing unit (GPU), Eur. Phys. J. C 66 (2010) 477, arXiv:0908.4403 [physics.comp-ph]

    2010 arXiv

  15. [23]

    Hagiwara, J

    K. Hagiwara, J. Kanzaki, Q. Li, N. Okamura, and T . Stelzer,Fast computation of MadGraph amplitudes on graphics processing unit (GPU), Eur. Phys. J. C 73 (2013) 2608, arXiv:1305.0708 [physics.comp-ph]

    2013 arXiv

  16. [24]

    Bothmann, W

    E. Bothmann, W . Giele, S. Hoeche, J. Isaacson, and M. Knobbe,Many-gluon tree amplitudes on modern GPUs: A case study for novel event generators, SciPost Phys. Codeb. 2022 (2022) 3, arXiv:2106.06507 [hep-ph]

    2022 arXiv

  17. [25]

    Carrazza, J

    S. Carrazza, J. Cruz-Martinez, M. Rossi, and M. Zaro, MadFlow: automating Monte Carlo simulation on GPU for particle physics processes, Eur. Phys. J. C 81 (2021) 7, 656, arXiv:2106.10279 [physics.comp-ph]

    2021 arXiv

  18. [26]

    Bothmann, T

    E. Bothmann, T . Childers, W . Giele, S. Höche, J. Isaacson, and M. Knobbe,A portable parton-level event generator for the high-luminosity LHC, SciPost Phys. 17 (2024) 3, 081, arXiv:2311.06198 [hep-ph]

    2024 arXiv

  19. [27]

    J. M. Cruz-Martinez, G. De Laurentis, and M. Pellen, Accelerating Berends–Giele recursion for gluons in arbitrary dimensions over finite fields, Eur. Phys. J. C 85 (2025) 5, 590, arXiv:2502.07060 [hep-ph]

    2025 arXiv

  20. [28]

    Valassi, S

    A. Valassi, S. Roiser, O. Mattelaer, and S. Hageboeck,Design and engineering of a simplified workflow execution for the MG5aMC event generator on GPUs and vector CPUs, EPJ Web Conf. 251 (2021) 03045, arXiv:2106.12631 [physics.comp-ph]

    2021 arXiv

  21. [29]

    Valassi, T

    A. Valassi, T . Childers, L. Field, S. Hageboeck, W . Hopkins, O. Mattelaer, N. Nichols, S. Roiser, and D. Smith,Developments in Performance and Portability for MadGraph5_aMC@NLO, PoS ICHEP2022 (2022) 212, arXiv:2210.11122 [physics.comp-ph]

    2022 arXiv

  22. [30]

    A. Valassi et al., Speeding up Madgraph5 aMC@NLO through CPU vectorization and GPU offloading: towards a first alpha release, in 21th International Workshop on Advanced Computing and Analysis Techniques in Physics Research: AI meets Reality. 3, 2023. arXiv:2303.18244 [physics....

    2023 arXiv

  23. [31]

    Hageboeck, T

    S. Hageboeck, T . Childers, W . Hopkins, O. Mattelaer, N. Nichols, S. Roiser, J. Teig, A. Valassi, C. Vuosalo, and Z. Wettersten,Madgraph5_aMC@NLO on GPUs and vector CPUs Experience with the first alpha release, EPJ Web Conf. 295 (2024) 11013, arXiv:2312.02898 [physics.comp-ph]

    2024 arXiv

  24. [32]

    Valassi, T

    A. Valassi, T . Childers, S. Hageböck, D. Massaro, O. Mattelaer, N. Nichols, F . Optolowicz, S. Roiser, J. Teig, and Z. Wettersten,Madgraph on GPUs and vector CPUs: towards production (The 5-year journey to the first LO release CUDACPP v1.00.00), in 27th International Conferen...

    2025

  25. [33]

    Alwall, R

    J. Alwall, R. Frederix, S. Frixione, V . Hirschi, F . Maltoni, O. Mattelaer, H. S. Shao, T . Stelzer, P . Torrielli, and M. Zaro,The automated computation of tree-level and next-to-leading order differential cross sections, and their matching to parton shower simulations, JHEP...

    2014 arXiv

  26. [34]

    de Aquino, W

    P . de Aquino, W . Link, F . Maltoni, O. Mattelaer, and T . Stelzer,ALOHA: Automatic Libraries Of Helicity Amplitudes for Feynman Diagram Computations, Comput. Phys. Commun. 183 (2012) 2254, arXiv:1108.2041 [hep-ph]

    2012 arXiv

  27. [35]

    CPU models from job monitoring

    A. Sciabà, “CPU models from job monitoring.” https://indico.cern.ch/event/1072141/, Mar, 2022

    2022

  28. [36]

    Maltoni and T

    F . Maltoni and T . Stelzer,MadEvent: Automatic event generation with MadGraph, JHEP 02 (2003) 027, arXiv:hep-ph/0208156

    2003 arXiv

  29. [37]

    Kleiss, W

    R. Kleiss, W . Stirling, and S. Ellis,A new monte carlo treatment of multiparticle phase space at high energies, Computer Physics Communications 40 (1986) 2, 359

    1986

  30. [38]

    Eberhart, J

    P . Eberhart, J. Brajard, P . Fortin, and F . Jézéquel,High performance numerical validation using stochastic arithmetic, Reliable Computing 21 (2015) 35

    2015

  31. [39]

    Jézéquel, J.-L

    F . Jézéquel, J.-L. Lamotte, and I. Said,Estimation of numerical reproducibility on CPU and GPU, in 8th Workshop on Computer Aspects of Numerical Algorithms (CANA), Federated Conference on Computer Science and Information Systems (FedCSIS). Sept., 2015

    2015

  32. [40]

    OpenMP Application Programming Interface Version 6.0

    OpenMP Architecture Review Board, “OpenMP Application Programming Interface Version 6.0.” https://www.openmp.org/specifications/, November, 2024. OpenMP API 6.0 Specification

    2024

  33. [41]

    Intel® 64 and IA-32 Architectures Optimization Reference Manual: Volume 1

    Intel Cerporation, “Intel® 64 and IA-32 Architectures Optimization Reference Manual: Volume 1.” https://intel.com/content/www/us/en/content-details/821612/intel64- and-ia-32-architectures-optimization-reference-manual-volume-1.html, April, 2024. Chapter 2: Intel® 64 and IA-32 ...

    2024

  34. [42]

    Nethercote and J

    N. Nethercote and J. Seward, Valgrind: a framework for heavyweight dynamic binary instrumentation, SIGPLAN Not. 42 (June, 2007) 89–100

    2007

  35. [43]

    Weidendorfer, M

    J. Weidendorfer, M. Kowarschik, and C. Trinitis,A tool suite for simulation based analysis of memory access behavior, in Computational Science - ICCS 2004, M. Bubak, G. D. van Albada, P . M. A. Sloot, and J. Dongarra, eds. Springer Berlin Heidelberg, Berlin, Heidelberg, 2004

    2004

  36. [44]

    perf: Linux profiling with performance counters

    A. C. de Melo, “perf: Linux profiling with performance counters.” https://perfwiki.github.io/main/, 2009. Available as part of the Linux kernel. 39 SciPost Physics Submission

    2009

  37. [45]

    Enhancing software-hardware co-design for hep by low-overhead profiling of single- and multi-threaded programs on diverse architectures with adaptyst

    M. Graczyk and S. Roiser, “Enhancing software-hardware co-design for hep by low-overhead profiling of single- and multi-threaded programs on diverse architectures with adaptyst.” arXiv:2502.20947 [cs.PF], 2025

    2025 arXiv

  38. [46]

    Flame Graphs — brendangregg.com

    B. Gregg, “Flame Graphs — brendangregg.com.” https://www.brendangregg.com/flamegraphs.html, December, 2011. Introduction to FlameGraphs hosted on Brendan Gregg’s personal website

    2011

  39. [47]

    CUDACPP Wiki

    S. Hageböck, S. Roiser, D. Smith, and A. Valassi, “CUDACPP Wiki.” https://github.com/madgraph5/madgraph4gpu/wiki, March, 2020. GitHub repository for CUDACPP

    2020

  40. [48]

    Carrazza, J

    S. Carrazza, J. M. Cruz-Martinez, and M. Rossi, PDFFlow: Parton distribution functions on GPU, Comput. Phys. Commun. 264 (2021) 107995, arXiv:2009.06635 [hep-ph]

    2021 arXiv

  41. [49]

    LHAPDF Kokkos version on GitLab

    M. Knobbe, “LHAPDF Kokkos version on GitLab.” https://gitlab.com/hepcedar/lhapdf/-/tree/kokkos_version?ref_type=heads, March,

  42. [50]

    Bothmann, T

    E. Bothmann, T . Janßen, M. Knobbe, T . Schmale, and S. Schumann,Exploring phase space with Neural Importance Sampling, SciPost Phys. 8 (2020) 4, 069, arXiv:2001.05478 [hep-ph]

    2020 arXiv

  43. [51]

    Heimel, R

    T . Heimel, R. Winterhalder, A. Butter, J. Isaacson, C. Krause, F . Maltoni, O. Mattelaer, and T . Plehn,MadNIS - Neural multi-channel importance sampling, SciPost Phys. 15 (2023) 4, 141, arXiv:2212.06172 [hep-ph]

    2023 arXiv

  44. [52]

    Heimel, N

    T . Heimel, N. Huetsch, F . Maltoni, O. Mattelaer, T . Plehn, and R. Winterhalder,The MadNIS reloaded, SciPost Phys. 17 (2024) 1, 023, arXiv:2311.01548 [hep-ph]

    2024 arXiv

  45. [53]

    Heimel, O

    T . Heimel, O. Mattelaer, T . Plehn, and R. Winterhalder,Differentiable MadNIS-Lite, SciPost Phys. 18 (2025) 1, 017, arXiv:2408.01486 [hep-ph]

    2025 arXiv

  46. [54]

    Efficient many-jet event generation with flow matching

    E. Bothmann, T . Janßen, M. Knobbe, B. Schmitzer, and F . Sinz, “Efficient many-jet event generation with flow matching.” arXiv:2506.18987 [hep-ph], 2025

    2025 arXiv

  47. [55]

    Wettersten, O

    Z. Wettersten, O. Mattelaer, S. Roiser, R. Schöfbeck, and A. Valassi,Acceleration beyond lowest order event generation. An outlook on further parallelism within MadGraph5_aMC@NLO, EPJ Web Conf. 295 (2024) 10001, arXiv:2312.07440 [physics.comp-ph]

    2024 arXiv

  48. [56]

    Hardware acceleration for next-to-leading order event generation within MadGraph5_aMC@NLO

    Z. Wettersten, O. Mattelaer, S. Roiser, A. Valassi, and M. Zaro, “Hardware acceleration for next-to-leading order event generation within MadGraph5_aMC@NLO.” arXiv:2503.07439 [hep-ph], March, 2025

    2025 arXiv

  49. [57]

    Welcome to the MadGraph5_aMC@NLO Wiki

    J. Alwall, M. Herquet, F . Maltoni, and O. Mattelaer, “Welcome to the MadGraph5_aMC@NLO Wiki.” https://cp3.irmp.ucl.ac.be/projects/madgraph/, September, 2009. UCLouvain-hosted Wiki for MadGraph5_aMC@NLO

    2009

  50. [58]

    MadGraph5_aMC@NLO in Launchpad

    MadTeam, “MadGraph5_aMC@NLO in Launchpad.” https://launchpad.net/mg5amcnlo, September, 2009. LaunchPad repository for MadGraph5_aMC@NLO. 40

    2009

  51. [2023]

    Kokkos port of the LHAPDF pdf library

Pith tools

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