Source-linked AI summary
A Multi-Threaded Version of MCFM
John M. Campbell, R. Keith Ellis, Walter T. Giele
TL;DR
Monte Carlo event-generator performance must exploit growing processor parallelism while preserving numerical integration results across thread counts. The paper implements OpenMP in MCFM by parallelizing VEGAS event evaluation and combining events for grid optimization, achieving strong acceleration, including about 100-fold speedup on Xeon-Phi for compute-intensive NLO processes. The implementation remains subject to runtime constraints such as per-thread stack size.
Problem
Monte Carlo event generators need faster evaluation to support more complicated processes and experimentation as processors increasingly provide computational power through multiple cores.
Method
The paper modifies MCFM's VEGAS integration with OpenMP, distributing independent event evaluations across threads while combining events for each iteration's grid optimization.
Results
The threaded MCFM accelerates across architectures; compute-intensive NLO processes scale well, with Xeon-Phi providing acceleration of order 100 over one thread.
Takeaways & Limitations
Faster MCFM evaluation can support more complicated processes, including additional jets or possible next-to-next-to-leading-order calculations.
Takeaways & Limitations
Each thread's stack size must be sufficient because an undersized stack can cause segmentation faults or other unexpected behavior.
Abstract
from arXiv · showhide
We report on our findings modifying MCFM using OpenMP to implement multi-threading. By using OpenMP, the modified MCFM will execute on any processor, automatically adjusting to the number of available threads. We modified the integration routine VEGAS to distribute the event evaluation over the threads, while combining all events at the end of every iteration to optimize the numerical integration. Special care has been taken that the results of the Monte Carlo integration are independent of the number of threads used, to facilitate the validation of the OpenMP version of MCFM.
1 Overview
MCFM is adapted to exploit increasingly multi-core processors through OpenMP, with parallel event evaluation and minimal code changes. The overview motivates this approach by processor trends, portability, and the need for faster Monte Carlo evaluation.
- Faster Monte Carlo evaluation enables more complicated processes and more experimentation by returning results sooner.
- MCFM targets multi-core processors because independently evaluated Monte Carlo events can be distributed across threads.The resulting event evaluations can then be combined for numerical integration.
- Increasing processor core counts, rather than frequencies, reflects power-consumption limits associated with higher clock speeds.The paper relates this trend to the need for software that uses multiple cores.
- The study tests OpenMP MCFM on systems ranging from four hardware threads to the 240-thread Intel Xeon-Phi.The tested platforms include Intel Core i7, dual Xeon, quad AMD Opteron, and Xeon-Phi systems.
- OpenMP supports portable shared-memory multiprocessing and allows parallelism through compiler directives with only minor source-code alterations.The same code remains compilable without the OpenMP compilation flag because directives are treated as comments.
2 Implementing OpenMP in MCFM
The OpenMP implementation parallelizes MCFM's event generation and evaluation while preserving shared VEGAS grid optimization and thread-independent results. Implementation work focuses on data ownership, random-number assignment, and numerically stable accumulation.
- 2.1 MCFM: MCFM uses VEGAS iterations to generate events and optimize an integration grid, while event generation and matrix-element evaluation require no inter-event data sharing.The grid optimization remains serial so results from all events can be combined for convergence.
- 2.1 MCFM: Combining events from all threads improves grid optimization compared with running separate MCFM instances whose grids see only thread-local events.
- 2.2 OpenMP-MCFM: The conversion minimizes changes to the original code, uses compiler directives, and aims to produce the same events regardless of thread count.The OpenMP code is intended to compile with or without the OpenMP flag.
- 2.2 OpenMP-MCFM: Parallelization requires deciding which variables are global and which are local to each thread, with substantial work devoted to data structures.
- 2.2 OpenMP-MCFM: DATA, SAVE, and common-block variables are handled with SAVE, THREADPRIVATE, and COPYIN directives to initialize and isolate thread-specific state.
- 2.2 OpenMP-MCFM: A serial CRITICAL region assigns random-number groups so the same events are generated, despite variable thread access order.Kahan summation reduces rounding differences from changing addition orders, producing identical and more accurate cross sections.
- 2.2 OpenMP-MCFM: All MCFM processes produce results independent of thread count and agree with the non-parallel MCFM 6.8 version.This agreement helps validate the parallel implementation.
3 Performance of OpenMP-MCFM
OpenMP-MCFM uses configurable thread counts and benchmarks performance across four hardware configurations for LO and NLO Higgs-plus-two-jet evaluations. NLO scaling is generally stronger, while LO performance becomes limited by memory bandwidth on higher-core systems.
- Implementation: OpenMP-MCFM uses all available threads by default, with options to reduce the thread count; insufficient per-thread stack size can cause runtime failures.Compilation requires the OpenMP flag, and the program can otherwise run without multi-threading.
- Intel Core i7: 3.80 LO and 3.79 NLO acceleration are achieved on four Core i7 threads, while additional hyperthreads provide slower incremental speedups.Acceleration reaches 5.25 at eight threads for LO and 4.91 for NLO; the configuration generates around 6.3 million NLO Vegas events per hour, depending on cuts.
- Dual Intel Xeon X5650: 11.16 LO and 11.97 NLO maximum acceleration are obtained on the 12-core X5650 system, which generates 8.7 million NLO Vegas events per hour.The passage attributes the stronger NLO scaling to computationally bound work and the weaker LO scaling to bandwidth limitations.
- Quad AMD Opteron: 31.82 NLO acceleration is achieved on the 32-core AMD system, while LO peaks at 11.44 using 16 cores and slows with more cores.The AMD configuration generates 14.2 million NLO Vegas events per hour despite a per-processor speed factor of 0.35 relative to the Core i7.
- Intel Xeon-Phi: 119 maximum NLO acceleration is achieved on the 240-thread Xeon-Phi, whereas LO peaks near 16.61 acceleration at about 32 threads.The Xeon-Phi evaluates 31.82-second NLO runs and generates 10.7 million NLO Vegas events per hour; its single-core processing speed is a factor of 0.07 relative to the Core i7.
4 Conclusions
The threaded MCFM version accelerates well across different architectures, especially for computationally intensive NLO processes. The implementation reduces execution time according to available hardware, enabling more complex processes while maintaining strong acceleration.
- MCFM’s threaded version accelerates well across different processor architectures.
- NLO processes scale well with thread count and achieve significantly improved evaluation speeds.
- An Intel Xeon-Phi coprocessor with 240 hardware cores yields an acceleration of order 100 over a single thread.
- Improved MCFM speed can support more complicated processes, including additional jets or NNLO processes, with acceptable evaluation times.