arXiv:2607.05018v1 [physics.comp-ph] 6 Jul 2026
Watts per event: evaluating Sustainability of HEP Event Generators beyond the LHC era Szabolcs Molnár1 , Gábor Bı́ró1 , Gábor Papp2 , Gergely Gábor Barnaföldi1 1
Department of Theoretical Physics, HUN-REN Wigner Research Centre for Physics, 29-33 Konkoly-Thege Miklós rd., Budapest, 1121, Hungary. 2 Department of Theoretical Physics, Eötvös Loránd University, Pázmány Péter Sétány 1/A, Budapest, H-1117, Hungary.
Contributing authors: [email protected]; [email protected]; [email protected]; [email protected]; Abstract The development, tuning and operation of Monte Carlo event generators beyond the LHC era require vast amount of resources. In this study we investigate the sustainability of these software with a containerized set of tools (named 77rev/propripy), by benchmarking the HIJING++ heavy-ion Monte Carlo event generator. We analyze the performance of various CPU architectures and show that by choosing the level of multithreading properly, the cost of event generation can be optimized. The presented approach can reduce the energy footprint of high-energy physics event generators and therefore alleviate the ever-increasing, ubiquitous computational challenges.
1 Introduction The upcoming High-Luminosity LHC (HL-LHC), and later the Future Circular Collider (FCC) era present unprecedented computational challenges, as the required scale of simulated data is expected to increase by an order of magnitude [1–4]. Monte Carlo (MC) event generation remains one of the most resource-intensive components of the HEP computing pipeline, often consuming a majority of the total CPU power provided by the Worldwide LHC Computing Grid (WLCG) [5]. As the community shifts
1
toward a ”carbon-aware” computing model, the metric for success is evolving from simple event throughput to sustainable efficiency [6]. This becomes especially important if the globally increasing hardware prices are showing an increasing trend. Monte Carlo event generators are computational tools that simulate the complete evolution of particle collisions. The calculations are separated into two parts: hard and soft processes. Quantum Chromodynamics (QCD) is a non-abelian gauge theory that describes the strong interaction [7]. On high energies QCD is perturbative, while on low energies where the coupling becomes strong it is non-perturbative. This nonperturbative energy domain is what we refer to as soft QCD and is handled by effective theories or phenomenology. Overall, these properties make it challenging to model particle collisions accurately. The non-perturbative nature of the soft processes and the requirement to model both hard and soft parts necessitate many parameters, some of which are non-physical. For the model to have predictive power, all of the parameters have to be tuned [8, 9] using experimental data, e.g. from the LHC [10]. In the following sections, we introduce a scoring system to measure efficiency, and a specifically developed toolbox for its evaluation. We illustrate the methodology by presenting the results measured via a heavy-ion Monte Carlo event generator at LHC and FCC energies.
2 Efficiency Scoring Current HEP computing demands a departure from traditional ”time-to-completion” metrics. As software grows more complex—incorporating deep multithreading and vectorization—the hardware utilization profile changes significantly. Modern workloads require a benchmarking approach that prioritizes real-world application performance over synthetic instruction sets. By focusing on the operational efficiency of specific production tasks, researchers can better understand how hardware limitations, such as memory bandwidth and thermal throttling, impact the overall throughput of large-scale simulation campaigns. To evaluate the sustainability of an event generator, a ”price” metric can be defined to measure the total energy consumed to produce a single physics event. The HEPScore23 (HS23) framework shifts benchmarking toward throughput-per-watt metrics using real production workloads [11]. This energy cost can be achieved by correlating the average consumed power (P) in Watts, with the event throughput (Tevent ) in events per second:
Eevent =
Pavg . Tevent
(1)
This allows us to keep track of the efficiency of any event generator across different levels of parallelism, assuming that for the benchmarking the CPUs were dedicated to this task only. In turn, we can ascertain which level of parallelism (i.e., how many threads) is optimal. 2
3 Motivation: Monte Carlo tuning Simulating heavy ion collisions—and consequently the tuning of a heavy-ion event generator—is especially challenging. Parameter tuning is an iterative process, where one minimizes the cost function. For this step we are using the Professor tool [8]. The process begins with a stochastic sampling from a defined range of parameter values, resulting in a large set of parametrisations that the event generator has to be evaluated on. This results in a vast amount of generated data that needs to be used for the MC parameter optimisation. This process involves many tools that need to interact with each other, e.g., in our example the Monte-Carlo step produces files in HepMC3 format, which is processed via a Rivet [12] analysis, followed by creation a physically relevant data structures through YODA files. In the last step, Professor can be invoked to interpolate the results and perform the cost function minimization—quite often in several passes, with variable weights, limit ranges of parameters and initial values.
4 Methodology As the whole tuning process involves tedious and technically complex processes to be performed many times, a specific toolbox has been built in order to facilitate the tuning. The toolbox is available as a Docker image (on Docker Hub), named 77rev/proripy [13] (Professor, Rivet and Pythia8). The image makes it easy to use the included tools without step-by-step installation and maintenance. Furthermore, the image includes several compilers, making it possible to debug and run code inside the container. Additionally, this tool can be used to determine the optimal parallelisation level of the whole framework on a given hardware, which results in a more efficient procedure. The current versions of tools in the image are summarized in Table 1. The default tune of Pythia8–the Monash tune [14]–requires over 30 pages just to present the results. It has different sets of parameters for different goals and finetunings, tuned for a lot more results than what is presented in this work. Presenting a full tuning process is outside the scope of this paper. Table 1 Included main packages and their versions Package
Rivet
Pythia8
Professor
ROOT
YODA
HepMC3
GDB
Version
4.1.0
8.316
2.4.2
6.36.04
2.1.0
3.3.1
12.1
Package
FastJet5
HighFive
Ruby
C/C++
Rust
Python
Go
Version
3.4.3
2.10.1
3.0.2p107
11.4.0
1.28.2 (rustup)
3.10.12
1.18.1
In this study, we demonstrate the importance of optimal parallelisation level, motivated by the high computation requirements of the tuning process, by benchmarking and evaluating several hardware architectures using the 77rev/proripy toolbox. 3
Additionally, preliminary tuning results of the HIJING++ (Heavy Ion Jet INteraction Generator) MC event generator, developed in C++ with CPU multithreading capabilities, are shown as an illustration of the method [15–27]. We tested the performance generating 500,000 pp events and 10,000 Pb-Pb events with detailed HepMC3 formatted output, while no other processes (besides the systemprocesses running in the background) were running to ensure the accurate power measurements. The script for benchmarking is included in the image, located at /home/devuser/Scripts. It also requires the power.sh script, which has to be in the same folder. The script has to be run via a privileged docker container with root permissions so that the powerstat linux package can have access to the hardware. The way the benchmarking scripts work, along with other technical details is explained on the Docker image’s Gitlab page [28].
4.1 Investigated architectures Here we present the impact of CPU multithreading on performance, as well as show the power consumption of multiple CPU architectures. With this, we can answer the question of which CPU is the most efficient (power consumption vs performance)—and, more importantly, what is the optimal level of parallelisation on a given architecture. The CPUs tested (single- and multithread) are shown in Table 2. By power consumption, we mean the CPU’s momentary power consumption specifically (not the Thermal Design Power - TDP or Package Power Tracking - PPT). TDP is a thermal engineering specification that tells cooler manufacturers how much heat the processor is expected to generate under sustained workloads so they can design adequate cooling. In contrast, PPT is the actual electrical power cap enforced by the CPU’s own management firmware. On AMD platforms, PPT is a hard average wattage limit for the entire socket (cores, I/O die, memory controller), typically set at about 1.35 times the TDP, and the processor will not exceed it (for more than a very short burst at most). The powerstat (v0.02.27) tool measures the real-time power consumption of the CPU package by reading the RAPL (Running Average Power Limit) hardware energy counters—the very same model-specific registers the processor uses to enforce PPT—and it reports the actual power (watts) being drawn at that moment. Consequently, powerstat shows the power that is bounded by (but is not the value of) the PPT limit itself. The drives’ and the RAM’s power requirement would slightly elevate the values. However, the majority of the power consumption comes from the CPU anyway and to keep it from being overly complicated, it is best if we neglect the rest of the components (furthermore, it would also require different tools to measure the power consumption of other components). It was ensured that the memory (RAM) is not a bottleneck in either cases. When running this event generator it is important to have at least 32GB if not more, otherwise the RAM becomes a hard bottleneck (especially if it is DDR4 or older). The Intel Xeon CPU was paired with 32GB DDR3 RAM which was more than sufficient for the runs. 4
Table 2 CPU Details and specifications CPU Intel Xeon E5-2650 [29] AMD EPYC 7502P [30] AMD Ryzen 7 8845HS [31] AMD EPYC 4585PX [32]
Cores/Thr.
Clock (Base/Boost)
Cache
TDP
Year
2.00 / 2.80 GHz 2.50 / 3.35 GHz 3.80 / 5.14 GHz 4.30 / 5.75 GHz
20 MB 144 MB 24 MB 144 MB
95 W 180 W 54 W 170 W
2012 2019 2023 2025
8C/16T 32C/64T 8C/16T 16C/32T
The frequency was governed by the kernel’s built in CPUFreq subsystem. It has 3 parts, the core, scaling governors and scaling drivers. Scaling governors use algorithms to estimate the required CPU capacity so the subsystem can adjust it accordingly.
5 Results The tuning of Monte Carlo generators—the process of adjusting physical parameters to match experimental data—is an iterative and computationally expensive task requiring billions of events to be generated. If the underlying generation configuration is not optimized for energy efficiency, the cumulative carbon cost of a tuning campaign can be staggering. By integrating power-aware metrics into the tuning workflow (similarly to the HS23 metric), one can make informed decisions about the ”price” of precision, aligning with the long-term computational strategy of the High Luminosity LHC era. Below we show that by the configuration that yields the highest efficiency score, effectively treating energy as a finite budget, a more optimal tuning strategy can be utilized. The benchmarks were run for 16 threads but we only show 10 on the compact figures for better visibility.
5.1 HL-LHC era On Fig. 1 we show the summarized, compact results for AMD EPYC 4585PX on HLLHC energies. One might have expected that the drive type will play a significant role in the process (be a limiting factor in the case of HDDs), but the findings don’t necessarily support this claim. The HDD did indeed decrease the speed (by around 500 events/sec) but by far less than we expected. The no-write (NW) case simply shows the raw capability of the CPU without any limiting factor. Thus we can conclude that the limiting factor (in the case of newer CPUs) is the bandwidth between the components (CPU-memory and so on), which is not something the user has control over. Comparing the results of the Ryzen 7 8845HS and the EPYC 4585PX against the older CPUs might falsely lead us to believe that the difference in clockspeed is the most important metric. The deeper reason for this difference is the CPU architecture and how efficiently can the CPU be used by the program we are running (the newer CPU the better). These comparisons will be evaluated in detail in Section 7 and in Appendix A. The trends we see on the plot (power consumption and speed) is also heavily influenced by the MC event generator itself, how it is optimized, what CPU instructions could be utilized fully and so on. 5
Figure 1 Performance metrics of the AMD EPYC 4585PX at 7 TeV pp and 2.76 TeV Pb-Pb collisions.
On Fig. 2 the power cost of the event generation is plotted as defined in Eq. (1), with respect to the number of used threads. In every investigated case there is a clear optimum, a most advantageous thread number to choose per drive type, with the best event/s to power ratio. The results of all investigated CPU architectures, along with the changes of the runtimes of the optimal configurations compared to the fastest ones, are also summarized in Table 3. Table 3 Results table showing which number of threads is the fastest and most optimal for all tested CPUs. The measured times for the fastest values were taken as the reference (100%). CPU Intel Xeon E5-2650 AMD EPYC 7502P AMD Ryzen 7 8845HS AMD EPYC 4585PX - SSD AMD EPYC 4585PX - HDD AMD EPYC 4585PX - NW
pp 2 2 6 15 8 10
Fastest Pb-Pb 3 4 5 4 3 4
6
Most optimal pp Pb-Pb
Change in time pp Pb-Pb
2 2 4 5 6 10
100.0% 100.0% 104.1% 104.9% 113.7% 100.0%
3 4 3 3 3 4
100.0% 100.0% 113.9% 101.3% 100.0% 100.0%
Figure 2 Cost per event plot of the AMD EPYC 4585PX in all 3 cases - HL-HLC
We can observe a non-linear trend in the decrease of cost. The thread handling and additional steps that are required for multithreading, as apparent, consume time and/or energy in a rate which cancels out or even overtakes the gain from the multithreading itself. Interestingly, in Table 3 one can see that the difference between the fastest and optimal configurations becomes significant only for the newer CPU types. The runtime difference in all cases is almost negligible. In case of the newest EPYC 4585PX CPU, these differences are more pronounced: for pp collisions, the number increase of threads becomes sub-optimal above Nthreads > 5 for the SSD setup, while the fastest configuration is reached at Nthreads = 15. This indicates that a significant amount of energy can be saved by optimizing not to the runtime, but to the energy efficiency. 7
Additionally, for Pb-Pb collisions at the same CPU type, the most optimal setup is different only in the case of the SSD. In Section 7 the runtime speed of the optimal and fastest configurations will be compared in detail.
5.2 FCC era Generally, higher energies, especially in the case of heavy-ion collisions, require far more computational power. Overall, however, we can see on Fig. 3 that the same trends are preserved as in Fig. 1.
Figure 3 Performance metrics of the AMD EPYC 4585PX at 50 TeV pp and 39.4 TeV Pb-Pb collisions
Figure 4 shows the cost of each event with respect to the used number of threads, for SSD, HDD and NW cases respectively. It is immediately visible that these collision energy regimes are much more challenging to compute and the optimal level of multithreading is different than the LHC energies—moreover, in the case of Pb-Pb collisions the most optimal thread count was already found right away. These results can be seen in Table 4. 8
Figure 4 Cost per event plot of the AMD EPYC 4585PX, FCC energies, up to 10 threads.
6 Tuning results In the following subsections we present the pp tuning results for LHC energies, and we show the preliminary predictions of HIJING++ for 39.4 TeV Pb-Pb collisions.
6.1 HL-LHC era This section contains some recent results of the parameter tuning of HIJING++, for which the toolbox docker image was utilized. The results for pseudorapidity distribution are presented in Fig. 5. As √ it was detailed in Sec. 4, this process was done via the tuning tool Professor, at s = 0.9 TeV, 2.76 TeV, 7 TeV and 13 TeV collision energies in proton-proton systems [33–36]. Overall 6 parameters were tuned during this 9
Table 4 Results table showing which number of threads is the fastest and most optimal for the AMD EPYC 4585PX on FCC energies. The measured times for the fastest values were taken as the reference (100%). CPU AMD EPYC 4585PX - SSD AMD EPYC 4585PX - HDD AMD EPYC 4585PX - NW
pp 9 10 10
Fastest Pb-Pb 3 2 2
Most optimal pp Pb-Pb
Change in time pp Pb-Pb
4 5 10
114.3% 108.6% 100%
3 2 2
100% 100% 100%
process, with O(1000) sampled parametrization configs, 1-3 iterations, with 5 million events at each config—this results in O(6 · 1010 ) events for this simple tuning campaign. This is a very minimal setup, done for demonstrative purposes. A full, more rigorous tuning process would take far more time, and would require significantly more events.
Figure 5 Pseudorapidity distributions on HL-LHC energies [33–36]
The tuning process was focused only on the pseudorapidity distributions at multiple energies, see Fig. 5. We can state, that the technical side of the process was made very smooth by the Toolbox. We also managed to estimate the power requirement of the illustrated tuning campaign, which is presented in Table 5. 10
Table 5 Optimal vs Fastest mode power consumption estimates on HL-LHC energies for all tested CPUs. Each number was calculated with 1000 configurations (5 million event each) and with 10 iterations and 4 collision energies. CPU Intel Xeon E5-2650 AMD EPYC 7502P AMD Ryzen 7 8845HS AMD EPYC 4585PX - SSD AMD EPYC 4585PX - HDD AMD EPYC 4585PX - NW
Fastest (pp)
Optimal (pp)
Change
2 990 kWh 2 514 kWh 514 kWh 1 043 kWh 1 111 kWh 314 kWh
2 990 kWh 2 514 kWh 476 kWh 972 kWh 1 085 kWh 314 kWh
100% 100% 92.6% 93.2% 97.7% 100%
The first clear observation is that in such a scenario the overall power requirement of the relatively older CPUs can be significantly higher than the newer ones. Additionally, on these more recent architectures there is a difference between the fastest and optimal parallelisation level, favoring the more optimal layouts by ∼7%, which might lead to substantial energy saving on the long term. Finally, it might be surprising that the Ryzen 7 8845HS CPU used ∼50% less energy than the more recent EPYC 4585PX in SSD and HDD mode—however, it is important to emphasize that the former is a laptop CPU designed for high level of efficiency, and consequently, a sustained level of such a heavy workload might reduce the lifespan of the hardware. Here we only present the power consumption estimates for the proton-proton case—if one would run the MC event generator for heavy ion collisions, then the numbers would be inflated by several factors. Realistically speaking, at least ∼ 2 million events would be required to tune the MC event generator for heavy-ion collisions, so the power consumption would be roughly O(100) times more.
6.2 FCC era predictions The HIJING++ event generator code is still under development and under tuning for HL-LHC energies, but we can perform simulations for higher, FFC energies as √ well. Here the event generator predictions for sN N =39.4 TeV Pb-Pb collisions are presented: Fig. 6 shows the pseudorapidity distribution predictions of charged hadrons at various centrality classes. The rough estimate for the power consumption of a future tuning scenario for proton-proton collisions at one FCC energy is shown in Table 6. Such a tuning process is expected to be more power hungry than for HL-LHC energies, but again, an impactful amount of energy can be conserved by optimizing the level of multithreading.
7 Discussion As it has been shown in Sec. 5.1, the optimal level of multithreading might be different than the fastest one, depending on the actual hardware. For the older CPUs, the optimal and the fastest cases can be the same. On the other hand, on the more recent AMD EPYC 4585PX CPU, the required cost of event generation can be reduced by 29%, 33.65% and 32.9% for SSD, HDD and NW scenarios, respectively, by choosing the 11
Figure 6 Pseudorapidity distribution predictions for 39.4 TeV Pb-Pb collisions with centrality classes (0-5%, 5-10%, 70-80% and minimal bias).
Table 6 Optimal vs Fastest mode power consumption at FCC. Each number was calculated with 1000 configurations (5 million event each) with 10 iterations, at 1 energy value. CPU AMD EPYC 4585PX - SSD AMD EPYC 4585PX - HDD AMD EPYC 4585PX - NW
Fastest (pp)
Optimal (pp)
Change
531 kWh 506 kWh 176 kWh
515 kWh 471 kWh 176 kWh
97% 93% 100%
optimal configuration in Pb-Pb collision compared to the single core runs. However, the the actual runtime at the given level of multithreading is still to be investigated. Table 7 compares the runtime of the HIJING++ event generator in the two multithreaded configurations with respect to the single thread case. As expected, the multithreaded mode (either in the fastest or the optimal configuration) results in a substantial speedup in every case. What is more important, this speedup is very similar between the fastest and optimal cases (except for the older CPUs, where these two coincide), the runtimes of the optimal runs lag only a few percents behind. The amount of the saved energy can be notable in the optimal case, leading to prominent energy cost reduction—the tradeoff is only a negligible increase in runtime. 12
Table 7 Multithread modes compared to the single thread mode. The measured runtimes of the single thread modes were taken as the reference (100%). CPU
Change in time - fastest pp Pb-Pb
Change in time - optimal pp Pb-Pb
Intel Xeon E5-2650 AMD EPYC 7502P AMD Ryzen 7 8845HS AMD EPYC 4585PX - SSD AMD EPYC 4585PX - HDD AMD EPYC 4585PX - NW
67.2% 75.4% 49.8% 44.0% 43.6% 19.7%
67.2% 75.4% 51.8% 50.3% 47.3% 19.7%
59.3% 59.0% 49.9% 81.1% 92.4% 93.9%
59.3% 59.0% 56.8% 81.1% 92.4% 93.9%
Table 8 Multithread modes compared to the single thread mode, FCC energies. The measured runtimes of the single thread modes were taken as the reference (100%). CPU - Drive
Change in time - fastest pp Pb-Pb
Change in time - optimal pp Pb-Pb
AMD EPYC 4585PX - SSD AMD EPYC 4585PX - HDD AMD EPYC 4585PX - NW
43.98% 43.59% 19.66%
50.26% 47.33% 19.66%
81.11% 92.39% 93.94%
81.11% 92.39% 93.94%
As it has been shown on Fig. 3, the energy consumption, runtime and multithreading relations are similar even at FCC collision energies. In Table 8 we show the same runtime comparisons with respect to the single threaded mode for the EPYC 4585PX CPU. As it was in the HL-LHC era, a good amount of speedup can be achieved with the multithreading—however, this speedup is more moderate for the Pb-Pb collisions. In all of the above detailed cases we utilized the HIJING++ Monte Carlo event generator with a demonstrative tuning scenario to show that the level of multithreading can be optimized compared to the naive performance gain, therefore the energy footprint can be reduced. We investigated a handful of various CPU architectures— however, the same principle can be generalized and applied to other parallelizable calculations and hardware configurations as well. Eventually, this approach might ease the forthcoming computational challenges and lead to a more sustainable operation of event generators for the HL-LHC and FCC era.
8 Summary Given the recent increase in computational requirements worldwide, the question of how multithreading impacts the sustainability and efficiency of Monte Carlo event generators led to the conclusions of this study. Various CPUs were tested to determine the optimal and most efficient level of parallelisation. Using the Toolbox, which includes all the necessary tools for the development and tuning of Monte Carlo event generators like HIJING++, can not only speed up the process but also provide a feasible method for comparing hardware. The 77rev/proripy:4.4 Docker image contains also the benchmarking script(s) that made it possible. 13
We have shown that the given CPU architecture and the optimal level of multithreading play a significant role in the sustainable operation of MC event generators. The newer hardware is proven to be more efficient: we tested the AMD EPYC 4585PX the most extensively. The difference between drive type (SSD vs HDD) revealed only slight differences. Additionally, the AMD EPYC 4585PX has been tested and benchmarked for FCC √ √ energies at s =50 TeV proton-proton, and sN N =39.4 TeV Pb-Pb collisions, leading to similar conclusions: for the beyond LHC era of collider experiments, the efficient usage of the available computational resources plays a crucial role in sustainability.
Acknowledgement The authors would like to thank the support of the Hungarian National Research, Development and Innovation Office (NKFIH) grants under the contract numbers NKKP ADVANCED 25-153456, 2025-1.1.5-NEMZ KI-2025-00005, 2025-1.1.5NEMZ KI-2025-00013, 2024-1.2.5-TÉT-2024-00022. Computational resources were provided by the Wigner Scientific Computing Laboratory (WSCLAB).
References [1] Zurbano Fernandez, I., et al.: High-Luminosity Large Hadron Collider (HLLHC): Technical design report 10/2020 (2020) https://doi.org/10.23731/ CYRM-2020-0010 [2] Agostini, P., et al.: The Large Hadron–Electron Collider at the HL-LHC. J. Phys. G 48(11), 110501 (2021) https://doi.org/10.1088/1361-6471/abf3ba arXiv:2007.14491 [hep-ex] [3] Abada, A., et al.: FCC-ee: The Lepton Collider: Future Circular Collider Conceptual Design Report Volume 2. Eur. Phys. J. ST 228(2), 261–623 (2019) https://doi.org/10.1140/epjst/e2019-900045-4 [4] Abada, A., et al.: FCC Physics Opportunities: Future Circular Collider Conceptual Design Report Volume 1. Eur. Phys. J. C 79(6), 474 (2019) https: //doi.org/10.1140/epjc/s10052-019-6904-3 [5] Bird, I., et al. (eds.): LHC computing Grid. Technical design report (2005) [6] Aad, G., et al.: The environmental impact, carbon emissions and sustainability of computing in the ATLAS experiment. Eur. Phys. J. C 85(12), 1397 (2025) https://doi.org/10.1140/epjc/s10052-025-14976-3 arXiv:2505.08530 [hep-ex] [7] Acharya, S., et al.: The ALICE experiment: a journey through QCD. Eur. Phys. J. C 84(8), 813 (2024) https://doi.org/10.1140/epjc/s10052-024-12935-y arXiv:2211.04384 [nucl-ex] 14
[8] Buckley, A., Hoeth, H., Lacker, H., Schulz, H., Seggern, J.E.: Systematic event generator tuning for the LHC. Eur. Phys. J. C 65, 331–357 (2010) https://doi. org/10.1140/epjc/s10052-009-1196-7 arXiv:0907.2973 [hep-ph] [9] Lazzarin, M., Alioli, S., Carrazza, S.: MCNNTUNES: Tuning Shower Monte Carlo generators with machine learning. Comput. Phys. Commun. 263, 107908 (2021) https://doi.org/10.1016/j.cpc.2021.107908 arXiv:2010.02213 [physics.comp-ph] [10] Evans, L., Bryant, P.: LHC Machine. JINST 3, 08001 (2008) https://doi.org/10. 1088/1748-0221/3/08/S08001 [11] Szczepanek, N., Britton, D., Di Girolamo, A., Ketele, E., Glushkov, I., Giordano, D., Ondris, L., Simili, E., Borge, G.M.: HEP Benchmark Suite: Enhancing Efficiency and Sustainability in Worldwide LHC Computing Infrastructures. (2024) [12] Bierlich, C., Buckley, A., Butterworth, J.M., Gutschow, C., Lonnblad, L., Procter, T., Richardson, P., Yeh, Y.: Robust independent validation of experiment and theory: Rivet version 4 release note. SciPost Phys. Codeb. 36, 1 (2024) https: //doi.org/10.21468/SciPostPhysCodeb.36 arXiv:2404.15984 [hep-ph] [13] Molnár, S., Bı́ró, G., Barnaföldi, G.G.: 77rev/proripy Docker Image. Docker Hub. Tag: 4.4, [Online; accessed 01. 07. 2026] (2026). https://hub.docker.com/r/77rev/ proripy [14] Skands, P., Carrazza, S., Rojo, J.: Tuning pythia 8.1: the monash 2013 tune. European Physical Journal C 74(8) (2014) https://doi.org/10.1140/epjc/ s10052-014-3024-y [15] Albacete, J.L., et al.: Predictions for Cold Nuclear Matter Effects in p+Pb Colli√ sions at sN N = 8.16 TeV. Nucl. Phys. A972, 18–85 (2018) https://doi.org/10. 1016/j.nuclphysa.2017.11.015 arXiv:1707.09973 [hep-ph] [16] Barnaföldi, G.G., Bı́ró, G., Gyulassy, M., Harangozó, S.M., Lévai, P., Ma, G., Papp, G., Wang, X.-N., Zhang, B.-W.: First Results with HIJING++ in HighEnergy Heavy-Ion Collisions. Nucl. Part. Phys. Proc. 289-290, 373–376 (2017) https://doi.org/10.1016/j.nuclphysbps.2017.05.086 arXiv:1701.08496 [hep-ph] [17] Papp, G., Barnaföldi, G.G., Bı́ró, G., Gyulassy, M., Harangozó, S., Ma, G., Lévai, P., Wang, X.-N., Zhang, B.-W.: First Results with HIJING++ on High-energy Heavy Ion Collisions. PoS High-pT (015) (2018) arXiv:1805.02635 [hep-ph] [18] Bı́ró, G., Papp, G., Barnaföldi, G.G., Nagy, D., Gyulassy, M., Lévai, P., Wang, X.-N., Zhang, B.-W.: HIJING, a Heavy Ion Jet INteraction Generator for the High-Luminosity Era of the LHC and Beyond. MDPI Proc. 10(1), 4 (2019) arXiv:1811.02131 [physics.comp-ph]
15
[19] Bı́ró, G., Gábor Barnaföldi, G., Papp, G., Sándor Biró, T.: Multiplicity Dependence in the Non-Extensive Hadronization Model Calculated by the HIJING Framework++. Universe 5(6), 134 (2019) arXiv:1905.11272 [hep-ph] [20] Bı́ró, G., Barnaföldi, G.G., Papp, G., Gyulassy, M., Lévai, P., Wang, X.-N., Zhang, B.-W.: Introducing HIJING++: the Heavy Ion Monte Carlo Generator for the High-Luminosity LHC Era. PoS HardProbes2018, 045 (2019) https://doi.org/ 10.22323/1.345.0045 arXiv:1901.04220 [physics.comp-ph] [21] Sjostrand, T.: The Lund Monte Carlo for Jet Fragmentation. Comput. Phys. Commun. 27, 243 (1982) https://doi.org/10.1016/0010-4655(82)90175-8 [22] Sjöstrand, T., Ask, S., Christiansen, J.R., Corke, R., Desai, N., Ilten, P., Mrenna, S., Prestel, S., Rasmussen, C.O., Skands, P.Z.: An introduction to PYTHIA 8.2. Comput. Phys. Commun. 191, 159–177 (2015) https://doi.org/10.1016/j.cpc. 2015.01.024 arXiv:1410.3012 [hep-ph] [23] Skands, P., Carrazza, S., Rojo, J.: Tuning PYTHIA 8.1: the Monash 2013 Tune. Eur. Phys. J. C 74(8), 3024 (2014) https://doi.org/10.1140/epjc/ s10052-014-3024-y arXiv:1404.5630 [hep-ph] [24] Christiansen, J.R., Skands, P.Z.: String Formation Beyond Leading Colour. JHEP 08, 003 (2015) https://doi.org/10.1007/JHEP08(2015)003 arXiv:1505.01681 [hep-ph] [25] Sjöstrand, T.: The Development of MPI Modeling in Pythia. Adv. Ser. Direct. High Energy Phys. 29, 191–225 (2018) https://doi.org/10.1142/9789813227767 0010 arXiv:1706.02166 [hep-ph] [26] Bierlich, C., Gustafson, G., Lönnblad, L., Shah, H.: The Angantyr model for Heavy-Ion Collisions in PYTHIA8. JHEP 10, 134 (2018) https://doi.org/10. 1007/JHEP10(2018)134 arXiv:1806.10820 [hep-ph] [27] Bierlich, C., et al.: A comprehensive guide to the physics and usage of PYTHIA 8.3. SciPost Phys. Codeb. 2022, 8 (2022) https://doi.org/10.21468/ SciPostPhysCodeb.8 arXiv:2203.11601 [hep-ph] [28] Toolbox for HEP. [Online; accessed 01. 07. 2026]. https://gitlab.wigner.hu/ szmlnr/toolbox-for-hep [29] Intel Xeon E5-2650. https://www.techpowerup.com/cpu-specs/xeon-e5-2650. c974. [Online; accessed 01. 07. 2026] [30] AMD EPYC 7502P. https://www.techpowerup.com/cpu-specs/epyc-7502p. c2260. [Online; accessed 01. 07. 2026] [31] AMD
Ryzen
7
8845HS.
https://www.techpowerup.com/cpu-specs/
16
ryzen-7-8845hs.c3400. [Online; accessed 01. 07. 2026] [32] AMD EPYC 4585PX. https://www.techpowerup.com/cpu-specs/epyc-4585px. c4172. [Online; accessed 01. 07. 2026] [33] Alver, B., et al.: Charged-particle multiplicity and pseudorapidity distributions measured with the phobos detector in Au + Au, Cu + Cu, d + Au, and p + p collisions at ultrarelativistic energies. Phys. Rev. C 83, 024913 (2011) https:// doi.org/10.1103/PhysRevC.83.024913 [34] √ Adam, J., et al.: Charged-particle multiplicities in proton–proton collisions at s = 0.9 to 8 TeV. Eur. Phys. J. C 77(1), 33 (2017) https://doi.org/10.1140/ epjc/s10052-016-4571-1 arXiv:1509.07541 [nucl-ex] [35] Acharya, S., et al.: Transverse momentum spectra and nuclear modification factors of charged particles in pp, p-Pb and Pb-Pb collisions at the LHC. JHEP 11, 013 (2018) https://doi.org/10.1007/JHEP11(2018)013 arXiv:1802.09145 [nuclex] [36] Adam, J., et al.: Pseudorapidity and transverse-momentum distributions of √ charged particles in proton–proton collisions at s = 13 TeV. Phys. Lett. B 753, 319–329 (2016) https://doi.org/10.1016/j.physletb.2015.12.030 arXiv:1509.08734 [nucl-ex]
Appendix A
Additional plots and tables
Initialization is required to set up the calculations and the objects that the code uses. Table A1 shows these times in a table format, while Fig. A1 shows it in a plot format. We also show the detailed benchmarking result breakdowns in Fig A2-A5.
17
Table A1 Initialization times across CPUs per thread and per pp/Pb-Pb collisions CPU
Thread pp [s]
Xeon E5-2650 Pb-Pb [s] pp [s] EPYC 7502P Pb-Pb [s] pp [s] Ryzen 7 8845HS Pb-Pb [s] pp [s] EPYC 4585PX Pb-Pb [s]
1 9
2 10
3 11
4 12
5 13
6 14
7 15
8 16
14.78 40.55 61.9 90.11
18.08 44.55 66.44 93.97
21.29 48.18 68.46 99.09
24.53 50.84 73.15 101.26
27.84 54.16 79.16 103.19
31.02 57.89 84.88 106.56
34.13 61.09 88.61 109.88
37.35 64.08 87.49 118.82
10.86 26.2 37.22 55.94
12.82 28.18 40.31 57.77
14.65 30 42.11 57.76
16.61 31.84 45.8 61.8
18.45 33.74 46.92 62.98
20.37 35.69 47.66 65.11
22.39 37.6 50.9 64.22
24.36 39.59 53.07 70.14
6.02 13.38 19.44 27.89
7.03 14.24 20.36 28.16
7.88 15.17 21.61 29.13
8.71 15.98 23.02 30.13
9.71 16.96 23.98 31.17
10.49 17.84 26.48 31.95
11.41 18.68 25.16 33.16
12.35 19.67 26.5 34.31
5.2 10.24 16.29 20.97
5.83 10.86 16.4 21.16
6.47 11.51 16.77 21.72
7.09 12.11 17.43 22.71
7.69 12.74 18.49 23.3
8.34 13.37 18.73 24.07
8.97 13.99 19.73 25.33
9.59 14.69 19.84 25.4
Figure A1 Initialization times per CPU, from Table A1
18
Figure A2 Detailed results for the AMD EPYC 4585PX on SSD
Figure A3 Performance metrics of the Intel Xenon E5-2650, on HDD
19
Figure A4 Performance metrics of the AMD Ryzen 7 8845HS, on SSD
Figure A5 Performance metrics of the AMD EPYC 7502P, on HDD
20