Initial explorations of ARM processors for scientific computing

Power efficiency is becoming an ever more important metric for both high performance and high throughput computing. Over the course of next decade it is expected that flops/watt will be a major driver for the evolution of computer architecture. Servers with large numbers of ARM processors, already ubiquitous in mobile computing, are a promising alternative to traditional x86-64 computing. We present the results of our initial investigations into the use of ARM processors for scientific computing applications. In particular we report the results from our work with a current generation ARMv7 development board to explore ARM-specific issues regarding the software development environment, operating system, performance benchmarks and issues for porting High Energy Physics software.

💡 Research Summary

The paper investigates the feasibility of using low‑power ARM processors for scientific computing, focusing on the CMS software stack (CMSSW) used by the Large Hadron Collider experiments. The authors begin by describing the growing computational demands of the LHC and the Worldwide LHC Computing Grid (WLCG), noting that future growth will be limited by power consumption rather than raw clock speed. Since around 2005, the industry has shifted from ever‑increasing clock frequencies to multicore designs, but this has led to a plateau in per‑core performance and a surge in overall power draw. In this context, ARM’s RISC architecture, which dominates the mobile market with excellent performance‑per‑watt, is presented as a potential alternative for server‑class workloads.

The experimental platform consists of a low‑cost ODROID‑U2 development board equipped with a Samsung Exynos 4412 Prime SoC (quad‑core Cortex‑A9, 1.7 GHz, 2 GB RAM, estimated TDP ≈ 4 W). The board runs Fedora 18 ARM Remix, a fully hard‑float Linux distribution similar to CERN’s Scientific Linux CERN (SLC). For comparison, two typical CERN x86‑64 servers are used: a dual‑quad‑core Xeon L5520 (2.27 GHz, 24 GB, 120 W TDP) and a dual‑hex‑core Xeon E5‑2630L (2.00 GHz, 64 GB, 120 W TDP). All machines execute the same CMS application: a Monte‑Carlo simulation of 8 TeV minimum‑bias events generated with Pythia8 and processed with Geant4. The application is single‑threaded, allowing a clean measurement of per‑core performance.

Porting CMSSW (≈ 3.6 M source lines, 125 external packages) to ARMv7 revealed several technical challenges. Oracle client libraries are unavailable for ARM, but the impact is limited because most CMS jobs access calibration data via the Frontier web service rather than direct Oracle calls. Compilation flags such as –m32/–m64 are unsupported, requiring a full transition to 64‑bit builds. Several code sections assumed x86‑specific signedness of char/bit‑fields; these were corrected by using –fsigned-char and –fsigned-bitfields and minor source edits. ROOT’s Cintex trampoline and I/O subsystems required patches to compile on ARM, which were contributed back to the ROOT developers. Memory pressure during dictionary generation was mitigated by refactoring the generated ROOT dictionaries.

Build times on the ODROID‑U2, performed directly on the board (rather than via cross‑compilation), were measured as follows: ~4 h for a bootstrap toolchain (GCC 4.8, basic libraries), ~12 h for the remaining external packages, and ~25.5 h for the CMSSW code itself, totaling roughly 42 h. The authors argue that, because external packages change infrequently, a nightly build strategy that reuses pre‑compiled externals is practical even on such modest hardware.

Performance results show that the ARM board processes 1.14 events per minute per core, whereas the Xeon L5520 and Xeon E5‑2630L achieve 3.50 and 3.33 events per minute per core, respectively. When normalized by thermal design power (TDP), the ARM processor delivers approximately 0.28 events · min⁻¹ · W⁻¹, an order of magnitude higher than the x86‑64 servers (≈ 0.03 events · min⁻¹ · W⁻¹). This demonstrates a clear advantage in performance‑per‑watt, despite lower absolute throughput.

The authors conclude that ARM‑based low‑power servers, if they achieve sufficient market penetration, could become a viable component of HEP high‑throughput computing infrastructures. The successful port of the full CMS software stack with relatively modest code modifications underscores the suitability of open‑source‑heavy scientific applications for ARM. Looking ahead, the upcoming 64‑bit ARMv8 architecture and the possibility of scaling to multi‑node ARM clusters promise further gains in energy efficiency, making ARM a compelling candidate for the next generation of power‑constrained high‑performance computing.