ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH-ENERGY PHYSICS

ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS August 2025 AUTHOR(S): Raisa Rahman Richi Franklin and Marshall College SUPERVISOR(S): Daniele Massaro Stefan Roiser Markus Schulz CERN openlab Report /2025 PROJECT SPECIFICATION CERN’s environmental strategy is built on three pillars: minimizing the laboratory’s environmental impact, reducing energy consumption while increasing energy reuse, and developing technologies that contribute to global sustainability. This project focused on the study of the power consumption and energy usage of MG5_aMC@NLO event generator (MadGraph), with the aim of assessing its environmental implications. We employed Single Instruction Multiple Threads (SIMT) GPUs (NVIDIA V100/A100), and Single Instruction Multiple Data (SIMD) CPUs, with, e.g., AVX2 instruction sets, to execute various processes. Event generation was carried out using MadGraph, and power consumption was systematically recorded during the runs. The recorded power data can then be used to calculate energy usage, from which the corresponding CO2emissions can be estimated, which would further provide insights into the environmental impact of these computational processes. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 1 CERN openlab Report /2025 ABSTRACT The objective of this project is to study the performance and energy consumption of Monte Carlo event generators used in high-energy physics simulations. The project builds upon ongoing efforts to optimize event generators such as MadGraph, evaluating their performance across various computational technologies, including GPU acceleration, and CPU-based acceleration using vector instructions. The work involves the use of monitoring tools to gain insights into hardware utilization, memory efficiency, and power consumption. This research has broader implications for the high-energy physics community, addressing the need for sustainable computational practices, and optimized computing infrastructure. It also offers the opportunity to contribute to cutting-edge research at the CERN IT department, collaborating with a team of experienced researchers. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 2 CERN openlab Report /2025 TABLE OF CONTENTS 1 Introduction 4 2 The MadGraph Event Generator 4 2.1 TheCUDACPPplugin................................ 4 2.2 ComputingArchitecture ............................... 5 2.2.1 SIMDCPUs.................................. 5 2.2.2 SIMTGPUs.................................. 5 3 Methodology 6 3.1 Preliminarytests ................................... 6 3.1.1 Running the MadEvent generator manually . . . . . . . . . . . . . . . . 6 3.1.2 Usinggridpacks................................ 7 3.2 Using a dedicated cluster node for power measurements . . . . . . . . . . . . . . 10 4 Results 11 4.1 Power measurements from the virtual machine . . . . . . . . . . . . . . . . . . . 11 4.1.1 Executing MadEvent manually . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2 Executing with Gridpacks . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Power measurement using CISM Cluster . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1 Gridpackcreation............................... 14 4.2.2 Running the event generation . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.3 Power measurements and CSV file creation . . . . . . . . . . . . . . . . . 16 5 Measuring the energy from power draw 19 6 Conclusions and Outlook 19 7 Acknowledgements 20 ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 3 CERN openlab Report /2025 1 Introduction High-energy physics research depends on large-scale computing, which consumes significant energy and contributes to CERN’s environmental footprint. To address this, CERN’s strategy focuses on minimizing impact, reducing and reusing energy, and developing sustainable technologies [1]. According to ATLAS 2022 Computing model, 20% of the computing resource will be occupied for event generation [2,3] during HL-LHC. Event generators such as MadGraph [4,5] and SHERPA [6] are central parts of particle physics simulations, but they can be computationally intensive. This project investigates the power consumption and energy usage of MadGraph on different architectures: SIMT GPUs (NVIDIA) and SIMD CPUs (with architectures AVX2 and AVX-512). This study is made possible by the recent release of the CUDACPP plugin for MadGraph [7], which enables offloading matrix element computations to both SIMT and SIMD hardware. Section 2provides an overview of MadGraph, followed by subsections introducing the new plugin and the relevant GPU and CPU architectures. Subsequent sections describe our methodology for power measurements, including manual runs of the MadEvent generator, execution with gridpacks (see section 3.1.2), and tests performed on a cluster. We also present the results derived from the measurements and outline the procedure for converting power usage into energy consumption, which would enable the calculation of the associated CO2numbers. The results offer insights into how computational choices affect environmental impact and highlight opportunities for more sustainable practices in high-energy physics computing. 2 The MadGraph Event Generator MadGraph is a Monte Carlo event generator widely used in particle physics to simulate collisions and study fundamental interactions. It allows users to define initial and final states of several processes, generate the corresponding Feynman diagrams, write the mathematical code related to them, and compute the key physical quantities such as cross sections. Using the generated code, MadGraph’s event generator MadEvent produces events, that are then written on LHEF [8]. The event generator is run automatically through a Python orchestration layer, that can be executed via the command-line interface that MadGraph provides. MadGraph is a code generator written in Python that can initially produce source code in FORTRAN, C, and C++ for the calculations. To incorporate hardware acceleration through SIMD and SIMT, new implementations using C++ vector instructions and GPU programming have been introduced. The first step towards hardware acceleration involved identifying the primary performance bottleneck. Profiling revealed that matrix element evaluation consumed the majority of runtime during event generation. This portion of the code was subsequently rewritten to leverage CPU vectorization and GPU computing, using CUDA for NVIDIA GPUs or HIP for AMD GPUs, significantly improving computational efficiency. 2.1 The CUDACPP plugin These new efforts have been incorporated in the MadGraph plugin CUDACPP [7]. The plugin has two new output modes: •madevent_gpu: to run processes on GPUs; •madevent_simd: to run processes using vectorized CPU instructions. We installed the CUDACPP plugin in MadGraph, by starting MadGraph and typing: ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 4 CERN openlab Report /2025 mg5> install cudacpp The plugin allows us to set the computational backend in the run_card.dat, or through the interactive interface. Listing 1shows how to generate a process in MadGraph and store it in a folder using the output command, here specifically in PROC_pp_ttx_gpu. It also illustrates how to set the cudacpp_backend to cuda. The plugin additionally accepts the following values, which are self-explanatory: fortran,cpp,cppnone,cppavx2,cpp512y. 1import model sm 2generate p p > t t~ 3output madevent_gpu PROC_pp_ttx_gpu 4launch PROC_pp_ttx_gpu 5set cudacpp_backend cuda Listing 1: MadGraph commands for GPU execution. 2.2 Computing Architecture These simulations are computationally demanding. Modern high-performance computing relies on a variety of architectures to execute instructions and process data efficiently. The choice of the computing architecture, within the characteristics of the algorithm in place, may impact significantly the execution time, and, as a result, the power consumption. In this study, we analyzed the differences in power consumption from the use of two complementary paradigms: SIMD and SIMT, comparing them with the original Fortran-based approach. 2.2.1 SIMD CPUs In a Single Instruction, Single Data (SISD) CPU, each instruction operates on a single data element at a time. While simple and effective for sequential tasks, SISD is inefficient for largescale scientific computations where the same operation must be applied repeatedly across many data elements. SIMD architectures, in contrast, allow a single instruction to be applied simultaneously to multiple data elements. Modern CPUs implement SIMD through vector instruction sets such as AVX2 and AVX-512, which enable operations on e.g. multiple floating-point values in a single cycle. MadGraph allows the user to select the architecture they want to compile the code against, or to automatically select the best one according to the system (using the setting cppauto) SIMD. Fig. 1shows how data is processed in sequential and parallel structure. The leftmost one shows one input and one output per cycle in a SISD architecture and the rightmost shows N inputs and N outputs per cycle in a SIMD architecture. 2.2.2 SIMT GPUs Alongside SIMD CPUs, Single Instruction, Multiple Threads (SIMT) GPUs provide another layer of parallelism for high-performance computing. SIMT extends the idea of SIMD to thousands of lightweight threads running concurrently on a GPU. These threads are organized into ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 5 CERN openlab Report /2025 Figure 1: Sequential vs parallel data processing, figure from [9]. groups called warps (typically 32 threads on NVIDIA GPUs), which execute the same instruction. While each thread has its own registers and can follow a unique control path, divergence within a warp can reduce efficiency since different branches must be synchronized. GPUs also feature a deep memory hierarchy, with registers, shared memory, and high-bandwidth global memory, making efficient memory access patterns essential for maximizing throughput. In this project, we primarily employed NVIDIA GPUs to execute the generated CUDA code through the CUDACPP plugin. This plugin leverages the SIMT execution model to map physics computations onto thousands of threads, enabling high throughput and efficient utilization of GPU resources. By exploiting the parallelism of SIMT, the computationally intensive tasks in our workflow—such as matrix element evaluations—benefit from significant acceleration compared to CPU-only execution. 3 Methodology 3.1 Preliminary tests Initially, to monitor power consumption by both the GPU and CPU, we used a shared virtual machine hosted on CERN infrastructure, equipped with an NVIDIA V100 GPU, and with an Intel®Xeon®Silver 4216 CPU. We performed these tests as preliminary tests and used a cluster later on. We run the MadGraph generated code in two modes. 3.1.1 Running the MadEvent generator manually A subprocess refers to a specific interaction or scattering process that occurs within the quark or parton structure of a particle during a particular high-energy reaction or collision. The MadEvent generator can be run manually for each subprocess that is generated by MadGraph. In this scenario, events will be generated only for the single subprocess selected, and only for one single phase space configuration. This mode gives us the liberty of testing the code and the monitoring tools. The MadEvent entry point is a single binary with the name madevent_<backend>, where <backend> can be one among cuda,fortran,avx2, etc. It additionally requires standard input to specify parameters like the number of events to generate, the amount of iterations, as well as the phase space configuration to use. The first compilation of the subprocesses should be done by running ./bin/generate_events, so that all jobs for each ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 6 CERN openlab Report /2025 subprocess are created. Then, in each P<n>* folder, multiple subfolders G<n> would be created, each one containing a certain parametrization of the parameter space. Additionally, they contain the file input_app.txt that lists the standard input to give to the madevent executable. The latter is created in each P<n>* folder, and it will be a symlink to the madevent_<backend> executable. For example, in the case of cuda backend, we executed madevent_cuda < input_app. txt, passing the standard input through the file input_app.txt as shown in Listing 2. A sample of input_app.txt, which sets the parameters for running MadEvent, is shown in Listing 3. The comments explain the purpose of each line. MadEvent runs only the phase space configuration specified in the last line. The first line indicates the number of events to be generated, while the next two numbers specify the number of repetitions of the process. MadEvent repeats this process iteratively until it reaches the desired accuracy, as indicated by the second line in Listing 3. The remaining parameters are not relevant for the purposes of our project. ./madevent < G<n>/input_app.txt Listing 2: madevent execution 16384 1 1 ! Number of events and max and min iterations 0.01 ! Accuracy 2 ! Grid Adjustment 0=none, 2=adjust 1 ! Suppress Amplitude 1=yes 0 ! Helicity Sum/event 0=exact 1 ! Phase space configuration to consider Listing 3: input_app.txt file While running the madevent executable, GPU power consumption was monitored using nvidia-smi, with the command: nvidia-smi --query-gpu=timestamp,power.draw,utilization.gpu --format=csv,noheader,nounits --loop-ms=500,→ storing the measurements in a CSV file. The tool nvidia-smi is a command-line utility provided by NVIDIA that reports GPU status and performance metrics such as utilization, memory usage, temperature, and power consumption. In this case, we chose the process gg>tt~g g g for our initial test because the computation of matrix element of the process takes a good fraction of time. We are constrained to use a single channel processes because each madevent executable runs only one single subprocess. In this subprocess, two gluons interact to produce a top-antitop pair (t t~) along with three additional gluons. 3.1.2 Using gridpacks One of the main users of event generators like MadGraph are the CERN LHC experiments. They generate large number of events, and typically run the event generation pipeline using ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 7 CERN openlab Report /2025 gridpacks. Gridpacks are precompiled packages that bundle multiple subprocesses together, and contain already all the required information to generate events. Since we wanted to apply our techniques to real world scenarios, we switched to using gridpacks from running MadEvent manually. To enable them, the option gridpack must be set to True in the run card. All subprocesses are then saved in a single archive file that can be executed collectively. The archive contains the entry point executable script run.sh to launch the run and generate events. In our scenario, we chose the multi-process event pp>tt~gggwhich is the extended version of the single-channel process we used in the previous case and we followed the steps detailed below: 1. Generate the desired process using MadGraph, using madevent_gpu for exporting with GPU support and madevent_simd for exporting with vectorized CPU support. 2. Save the process in a directory (e.g., PROC_pp_ttxggg_gpu) and set gridpack=True while launching it to enable gridpack generation. 3. After generation, a compressed gridpack file is created inside the process directory. Unzip this file to obtain the execution script run.sh. 4. Run the gridpack with: ./run.sh <events number> <seed number>. The Listing 4and 5show Python scripts that utilize the generated gridpacks to run the events. For what concerns power measurements: •GPU + Host Power logging (CUDA backend): To log GPU power consumption during the execution of ./run.sh <events number> <seed number>, we synchronized the GPU monitoring with nvidia-smi with the event generation process, and we saved the readings in a CSV file as shown in Listing 4. In the same way, the host power was logged in parallel with GPU power, using host monitoring tools. •Host Power logging (vectorized CPU backends): For vectorized CPUs (AVX2, AVX-512), host power consumption was recorded using host monitoring tools. In both cases, we ensured that the script automatically terminated and stopped recording host power measurements once the run of the gridpack had finished (see Listing 5). ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 8 CERN openlab Report /2025 1##define processes 2for process in "${processes[@]}";do 3jprocess_name=$(echo "$process"| xargs python -c "import sys; print( ''.join(sys.argv[1:]).replace('>','_').replace('~','x').replace(' ','_') )") ,→ ,→ 4for backend in $backends;do 5if [$backend == "cuda" ];then 6sbatch --partition=gpu --exclusive --gres=gpu:1 --job-name=${process_name}_${backend} --output=logs/${process_name}_${backend}_%j.out producing_gridpack.sh $backend $process ,→ ,→ ,→ 7else 8sbatch --partition=gpu --job-name=${process_name}_${backend} --output=logs/${process_name}_${backend}_%j.out producing_gridpack.sh $backend $process ,→ ,→ 9fi 10 done 11 done Listing 8: Submitting jobs for gridpack creation using Slurm. 4.2.2 Running the event generation After creating the gridpacks, we automated the events generation for the different processes and backends, as shown in Listing 9. We also run each combination of process and backend multiple times by varying the option -p of the gridpack executable, which selects how many different MadEvent instances are running in parallel. A sleep interval was introduced between runs to allow the CPU to cool down, ensuring that the conditions of each measurement were consistent. This made it possible to compare results across different runs and allowed the CPU to return to its idle state before starting new processes for each backend and p. The script start and end times were recorded in the log file along with the individual process and backend start and end times so that we could then match the timestamped power measurements sampled server side, and request the power measurements from the cluster afterwards. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 15 CERN openlab Report /2025 1##slurm commands go here 2##define processes, backends, and number of events 3 4echo "Starting full script at $(date +"%Y-%m-%d_%H-%M-%S")" 5 6for process in "${processes[@]}";do 7##define process name here 8for backend in $backends;do 9echo "=== Running for backend: $backend and process: $process_name ===",→ 10 ##command to change directory and unpack the zip file 11 for pin 4 2 1;do 12 echo "Sleeping for $sleep_time s before running $backend with p: $p, for process: $process_name",→ 13 sleep $sleep_time 14 echo "Starting running with p: $p, for process: $process_name with $backend at $(date +"%Y-%m-%d_%H-%M-%S")",→ 15 ./run.sh -p $p $n_events 24 16 echo "Ending running with p: $p, for process: $process_name with $backend at $(date +"%Y-%m-%d_%H-%M-%S")",→ 17 done 18 done 19 done 20 21 echo "Ending Full script at $(date +"%Y-%m-%d_%H-%M-%S")" Listing 9: Running events generation with Slurm. 4.2.3 Power measurements and CSV file creation We obtained the power measurements from the cluster, as shown in Listing 10. To facilitate later analysis, specifically for producing GPU and CPU power plots, we prepared a script to separate the GPU and CPU power readings from the cluster’s power measurement file, as illustrated in Listing 11. The elapsed time for each process and backend was calculated from the log file (lines 10–28 in Listing 11). The start and end times for each process and backend were then recorded from the log file and matched with the timestamps in the cluster’s power measurement file (lines 30–39 in Listing 11), which allowed us to extract the corresponding power consumption within that interval for each process, backend, and number of simultaneous MadEvent instances. The CSV file that was produced from the Listing 11 contains the power and elapsed time for each process and backend with different values of the -p flag. Finally, one could use this CSV file to produce plots of power for different values of -p, backend and process. For the GPU runs, we additionally recorded power using nvidia-smi. The data from the cluster still requires processing. The next step is a systematic analysis of the cluster’s power measurements, for which the team already has the relevant data. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 16 CERN openlab Report /2025 12025-08-16 23:59:40 1755381580 199 "mb-mil101: Check Power" 22025-08-16 23:59:29 1755381569 0 "mb-mil101: GPU Usage" 32025-08-16 23:58:46 1755381526 193 "mb-mil101: Check Power" 42025-08-16 23:57:58 1755381478 4.271 "mb-mil101: GPU 1 Power in decaWatts" 52025-08-16 23:57:57 1755381477 4.384 "mb-mil101: GPU 0 Power in decaWatts" 62025-08-16 23:57:04 1755381424 198 "mb-mil101: Check Power" 72025-08-16 23:55:27 1755381327 205 "mb-mil101: Check Power" 8... Listing 10: GPU and host power measurements. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 17 CERN openlab Report /2025 1with open(out_file_path)as out_file: 2out_lines=out_file.readlines() 3with open(power_file_path) as log_file: 4log_lines=log_file.readlines() 5summary=[] 6for backend in backends: 7for process in processes: 8process_name =process.replace(' ', '').replace('>','_').replace('~','x'),→ 9for p_val in p_values: 10 start_time=None 11 end_time=None 12 for line in out_lines: 13 if m:=start_pattern.search(line): 14 p,proc,bc,ts_str=m.groups() 15 if int(p) == p_val and proc == process_name and bc==backend:,→ 16 start_time=datetime.strptime(ts_str, 17 "%Y-%m-%d_%H-%M-%S") 18 19 if m:=end_pattern.search(line): 20 p,proc,bc,ts_str=m.groups() 21 if int(p) == p_val and proc == process_name and bc==backend:,→ 22 end_time=datetime.strptime(ts_str, 23 "%Y-%m-%d_%H-%M-%S") 24 25 if start_time and end_time: 26 break 27 elapsed_time=(end_time-start_time).total_seconds() 28 summary.append([backend,process_name,p_val,start_time,end_time, elapsed_time]),→ 29 30 power_data=[] 31 for line in log_lines: 32 if m:=power_pattern.search(line): 33 time_str,power_str=m.groups() 34 time=datetime.strptime(time_str,"%Y-%m-%d %H:%M:%S") 35 print('time is ',time) 36 print('start time is',start_time,'and end time is',end_time),→ 37 if start_time<=time<=end_time: 38 delta=(time-start_time).total_seconds() 39 power_data.append((delta,int(power_str))) 40 41 ##write to a csv file Listing 11: Power and elapsed time separation from log files. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 18 CERN openlab Report /2025 5 Measuring the energy from power draw Integrating the power draw over time gives the energy consumption. So we can use the plot of, e.g., the GPU power, (see Fig. 3) to calculate the energy consumed by the GPU in that run. The idle power of the GPU was subtracted to get the net power draw. In the CPU case, the idle power was calculated by taking measurements at the beginning and end of the run, where no workload was run, and then taking the average of these measurements as shown in line 13 of Listing 12. The lower and higher limit of 700 W and 740 W for the CPU power as mentioned in line 11 of Listing 12 were decided by observing the plot in Fig. 4. 1with open(gpu_file_path, "r")as f: 2reader =csv.reader(f) 3for row in reader: 4pwr =float(row[3]) 5gpu_power.append(pwr-24) 6 7with open(cpu_file_path, "r")as f: 8reader=csv.reader(f) 9for row in reader: 10 power_cpu=float(row[2]) 11 if 700<=power_cpu<=740: 12 cpu_power_limit.append(power_cpu) 13 average_cpu=sum(cpu_power_limit)/len(cpu_power_limit) 14 15 with open(cpu_file_path, "r")as f: 16 reader=csv.reader(f) 17 for row in reader: 18 power_cpu=float(row[2]) 19 cpu_power.append(power_cpu -average_cpu) 20 21 Energy_gpu=(np.trapz(gpu_power,gpu_elapsed))/3600000 ##Energy in kWh 22 Energy_cpu=np.trapz(cpu_power,cpu_elapsed)/3600000 ##Energy in kWh 23 Total_energy=Energy_gpu+Energy_cpu Listing 12: Energy calculation from power draw. 6 Conclusions and Outlook In this work, we prepared the complete infrastructure necessary to perform consistent power measurements of event generation in MadGraph. We developed scripts to separate GPU and CPU power usage on the cluster, enabling us to precisely attribute power consumption to different computational backends. We also implemented tools to calculate the energy consumption in kWh, providing a reliable basis for further analysis. Throughout the process, we have overcome challenges related to synchronizing log files with power measurements and automating workflows across different backends. Initial measurements have already been carried out, demonstrating the functionality of the framework. The produced ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 19 CERN openlab Report /2025 codes have been uploaded to a public github repository [10] and shared with the members of IT-FTI-PSE section, who will continue the project by performing further measurements and analyzing the data. The next steps will focus on systematically analyzing the collected data, computing the net energy consumption for various processes and backends, and extending the analysis to estimate the corresponding CO2emissions using electricity maps [11] as shown in Fig. 5. These maps report the amount of CO2emissions per kWh, which can then be used to calculate the total CO2emissions associated with the measured energy consumption, for example by using [12]. In summary, the groundwork for sustainable performance evaluation in high-energy physics simulations has been established, and the upcoming analysis will provide valuable insights into both computational efficiency and environmental impact. Figure 5: Screenshot from Electricity map website [11]. 7 Acknowledgements We would like to thank Olivier Mattelaer and the CISM resource team for providing access to their infrastructure, enabling us to run our workloads and collect the corresponding power metrics. References [1] CERN Accelerating Science (ATS). Sustainability.https://ats.web.cern.ch/Sustainability. Accessed: 2025-08-22. 2025. [2] ATLAS Collaboration. ATLAS HL-LHC Computing Conceptual Design Report. Tech. rep. Geneva: CERN, 2020. url:https://cds.cern.ch/record/2729668. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 20 CERN openlab Report /2025 [3] ATLAS Collaboration. ATLAS Software and Computing HL-LHC Roadmap. Tech. rep. Geneva: CERN, 2022. url:https://cds.cern.ch/record/2802918. [4] Johan Alwall et al. “MadGraph 5 : Going Beyond”. In: JHEP 06 (2011), p. 128. doi: 10.1007/JHEP06(2011)128. arXiv: 1106.0522 [hep-ph]. [5] J. Alwall et al. “The automated computation of tree-level and next-to-leading order differential cross sections, and their matching to parton shower simulations”. In: JHEP 07 (2014), p. 079. doi:10.1007/JHEP07(2014)079. arXiv: 1405.0301 [hep-ph]. [6] Enrico Bothmann et al. “Event generation with Sherpa 3”. In: JHEP 12 (2024), p. 156. doi:10.1007/JHEP12(2024)156. arXiv: 2410.22148 [hep-ph]. [7] Stephan Hageböck et al. “Data-parallel leading-order event generation in MadGraph5_aMC@NLO”. In: (July 2025). arXiv: 2507.21039 [hep-ph]. [8] J. Alwall et al. “A Standard format for Les Houches event files”. In: Comput. Phys. Commun. 176 (2007), pp. 300–304. doi:10.1016/j.cpc.2006.11.010. arXiv: hepph/0609017. [9] Jon Stokes. SIMD Architectures.url:https://arstechnica.com/features/2000/03/ simd/ (visited on 09/03/2025). [10] Raisa Rahman Richi. cern_openlab.https://github.com/rrichii/cern_openlab. GitHub repository. 2025. [11] Electricity Maps. Live 24/7 CO2 emissions of electricity consumption.url:https:// app.electricitymaps.com/map/ (visited on 08/22/2025). [12] Loïc Lannelongue, Jason Grealey, and Michael Inouye. “Green Algorithms: Quantifying the Carbon Footprint of Computation”. In: Advanced Science 8.2100707 (2021). doi: 10.1002/advs.202100707. ENERGY EFFICIENCY ANALYSIS OF THE MADGRAPH EVENT GENERATOR FOR HIGH ENERGY PHYSICS 21