PaperlayerView exact revision on arXiv

Source-linked AI summary

Toward Open ISA Supercomputing: A Comparative Study of RISC-V, Arm, and x86 Architectures on HPC Workloads

Emanuele Venieri, Giacomo Madella, Gabriele Ceccolini, Simone Manoni, Federico Ficarelli, Filippo Barbari, Jenny Lynn Almerol, Elisabetta Boella, Nitin Shukla, Simone Bnà, Luca Benini, Andrea bartolini

arXiv:2610.32632v2cs.DCcs.ARcs.PF

TL;DR

Prior studies are fragmented across processor generations, workloads, and methods, leaving RISC-V’s position against contemporary Arm and x86 systems difficult to assess. This paper evaluates the Sophgo SG2044 alongside the NVIDIA Grace and Intel Xeon platforms using synthetic benchmarks and applications. The SG2044 trails in absolute performance on classical HPC workloads, but leads the evaluated platforms in LLM decode scaling and energy efficiency while exceeding Intel in throughput.

  • Problem

    Prior studies are fragmented across processor families, benchmark suites, and application domains, and often omit energy-efficiency analysis, making contemporary cross-ISA comparisons difficult.

    Source: §1 · p. 1, §2.2.1 · p. 4

  • Method

    The study evaluates the Sophgo SG2044 against the NVIDIA Grace CPU Superchip and Intel Xeon Platinum 8480+ across synthetic benchmarks and applications, comparing performance and scalability.

    Source: §5 · p. 9, §6 · p. 17

  • Results

    8–15× behind the evaluated Intel and NVIDIA platforms across classical HPC workloads, the SG2044 at 64 cores achieves 22.2× relative scaling and 0.209 tok/J for LLM decode, the highest among evaluated platforms, and 17.4 tok/s versus Intel’s 14.0 tok/s.

    Source: §1 · p. 2, §6 · p. 17

  • Takeaways & Limitations

    The SG2044 combines an absolute-performance gap on classical HPC workloads with competitive scaling and energy efficiency on several workloads, particularly LLM decode.

    Source: §1 · p. 2, §6 · p. 17

Abstract

from arXiv · show

RISC-V is emerging as a candidate architecture for high-performance computing (HPC), but its competitiveness against established x86 and Arm processors remains difficult to assess because existing studies use different platforms, workloads, and methodologies, and rarely consider energy efficiency. Our work provides an evaluation of contemporary HPC RISC-V, Arm, and x86 processors using a common software stack and methodology. We characterize the Sophgo SG2044 and compare it with the NVIDIA Grace CPU Superchip and Intel Xeon Platinum 8480+ across four HPC benchmarks (STREAM, HPL, HPL-MxP, and HPCG) and four representative applications (iPIC3D, PLUTO, OpenFOAM, and llama$.$cpp). The version of HPL-MxP linked to OpenBLAS built and used for this work is made available as open-source software. The SG2044 reaches 8.02 GFLOP/s of FP64 performance and 7.8 GB/s of memory bandwidth per core, increasing to 294 GFLOP/s and 107 GB/s at 64 cores. L2-cache-aware process placement enables near-linear scaling up to 16 cores, beyond which memory-bandwidth saturation limits further gains. Across generations of RISC-V hardware, in the context of the Monte Cimone (MC) project, the SG2044-based MCv3 doubles both single-core performance and peak memory bandwidth relative to MCv2, while improving memory bandwidth, node-level FP64 performance, and energy efficiency by approximately 100x, 158x, and 10x, over MCv1. Against the Arm and x86 systems, the SG2044 shows 8-15x less absolute performance, reflecting its narrower vector resources and less advanced technology node, but delivers competitive scaling and energy efficiency on several workloads. Its most notable result is LLM decode, where 64-core execution provides the highest relative scaling and energy efficiency among the evaluated platforms while exceeding Intel in throughput. Our results show that RISC-V processors are closing the gap with the competition.

1. Introduction

The paper addresses fragmented cross-architecture HPC evidence with a common evaluation of contemporary RISC-V, Arm, and x86 platforms. It characterizes the SG2044, tracks RISC-V platform evolution, and reports both performance gaps and workload-specific strengths.

1. Introduction

  • The study responds to fragmented cross-architecture evaluations that often omit energy-efficiency analysis and leave contemporary x86, Arm, and RISC-V comparisons under a common methodology largely unexplored.Source: §1 · pp. 1–2
  • The evaluation applies a consistent methodology across synthetic benchmarks and scientific and AI applications, using the same toolchain and libraries whenever possible.Workloads include STREAM, HPL, HPL-MxP, HPCG, iPIC3D, PLUTO, OpenFOAM, and llama.cpp, spanning bandwidth, linear algebra, simulation, and inference.Source: §1 · p. 2
  • The SG2044 delivers 7.8 GB/s single-core memory bandwidth and 8.02 GFLOP/s FP64 performance, reaching 107 GB/s and 294 GFLOP/s at 64 cores.L2-cache-aware pinning improves scaling through 16 cores; memory-bandwidth saturation limits further gains.Source: §1 · p. 2
  • MCv3 doubles peak memory bandwidth and single-core performance over MCv2, while MCv1-to-MCv3 gains are approximately 100× in memory bandwidth, 158× in node-level FP64 performance, and 10× in energy efficiency.The generational comparison is situated within the Monte Cimone project [17].Source: §1 · p. 2
  • The SG2044 trails Arm and x86 by 8–15× in absolute performance on several workloads, yet delivers competitive scaling and energy efficiency, including strong LLM decode results.At 64 cores, LLM decode reaches 22.2× relative scaling, 0.209 tok/J, and 17.4 tok/s, exceeding Intel’s 14.0 tok/s.Source: §1 · p. 2
  • For compute-bound workloads such as HPL, normalized single-core performance follows a trend consistent with vector-unit width, making wider vectors a potential RISC-V improvement direction.Source: §1 · p. 2
  • The authors release an open-source HPL-MxP implementation linked against OpenBLAS for portable use on generic CPU systems.Source: §1 · p. 2

2. Related Works

Prior HPC processor studies have examined Arm, x86, and RISC-V from different angles, but fragmented platforms and workloads leave cross-ISA assessment incomplete. This work situates its evaluation against those gaps and the Monte Cimone project's longitudinal RISC-V infrastructure.

2.1. Arm and x86 HPC Characterization

  • Arm studies report workload-dependent comparisons with x86: memory-bandwidth-bound applications can benefit from Arm systems, while optimized x86 libraries or higher floating-point throughput can favor x86.Grace evaluations report competitive node-level performance in some workloads but not others; selected kernels showed up to 3.25× higher power efficiency for Grace than Sapphire Rapids.Source: §2.1 · p. 3

2.2. RISC-V Evaluation for HPC

  • RISC-V studies cover synthetic benchmarks, individual applications, and server-class systems, but prior work generally lacks broad real-world HPC workload characterization.Some evaluations use experimental hardware [18], embedded-class platforms, or focus primarily on micro-benchmarks and pseudoapplications [2].Source: §2.2 · p. 3

2.2.1. The Monte Cimone Project

  • Monte Cimone has evolved into a research infrastructure for successive generations of clustered RISC-V hardware, supporting software-stack evaluation and a longitudinal view of RISC-V evolution in HPC.The platform includes SLURM, EXAMON monitoring, shared home directories, and environment modules [17].Source: §2.2.1 · pp. 3–4
  • Existing literature remains fragmented across processor generations, benchmark suites, and application domains, leaving cross-ISA assessment under a common methodology and broad workload spectrum missing.Source: §2.2.1 · p. 4

3. Systems and Platforms

The study compares commercially available server-class representatives of x86, Arm, and RISC-V. Their architectural configurations differ in core organization, caches, vector support, and memory topology.

3. Systems and Platforms

  • The evaluation selects commercially available Intel Sapphire Rapids, NVIDIA Grace, and Sophgo SG2044 systems to compare the three major CPU ISA ecosystems.The hardware characteristics are summarized in Table 1.Source: §3 · p. 4, Table 1 · p. 4

3.1.1. Intel Xeon Platinum 8480+

  • The Intel system uses two Sapphire Rapids sockets with 112 total usable physical cores, four NUMA domains, AVX-512 and AMX, and a shared 105 MB L3 cache.Hyper-Threading was disabled and the frequency governor set to performance.Source: §3.1.1 · p. 4

3.1.2. NVIDIA Grace CPU Superchip

  • The Grace platform has two 72-core Armv9 processors, with Neoverse V2 cores, SVE2 support, and two NUMA domains linked through NVLink-C2C.Each die has a shared 114 MB L3 cache.Source: §3.1.2 · pp. 4–5

3.1.3. Sophgo SG2044

  • The SG2044 is a 64-core RV64GCV processor with RVV 1.0, organized as sixteen four-core clusters sharing 2 MB L2 caches and a 64 MB L3 cache.Its UMA system has 128 GB LPDDR5X memory; each core has a private 64 KB L1 data cache.Source: §3.1.3 · p. 5

4. Evaluation Methodology

The evaluation uses a consistent, community-supported software stack where possible, with mature architecture-specific optimizations, and combines synthetic benchmarks with applications. It also accounts for machine-specific process placement and power measurement when comparing platforms.

4. Evaluation Methodology

  • The evaluation uses common compilers, libraries, and runtimes where possible, while allowing mature, public architecture-specific optimizations and modeling power across a common domain.Power data combine IPMI telemetry with RAPL and hwmon where available, plus modeled fan and auxiliary-component power.Source: §4 · p. 5

4.1. NUMA aware process pinning

  • On SG2044, l2_cache_aware pinning delays L2 saturation by distributing processes across 16 clusters; on Grace and Sapphire Rapids, placement engages bandwidth across NUMA nodes.On SG2044 the advantage shrinks to match sequential placement after saturation; across NUMA platforms, using all bandwidth from the start is preferred despite cross-node MPI latency.Source: §4.1 · p. 5

4.2. Benchmark Suite and Applications

  • Synthetic benchmarks isolate throughput, bandwidth, and energy behavior, while applications assess end-to-end performance; experiments use strong scaling with a fixed problem size.The study evaluates STREAM, HPL, HPL-MxP, HPCG, iPIC3D, PLUTO, OpenFOAM, and llama.cpp.Source: §4.2 · pp. 5–6

4.2.1. Synthetic Benchmarks

  • STREAM uses a 120,000,000-element array per kernel, exceeding four times each system’s LLC; the reported representative kernel is Triad.Each execution has 10 timed repetitions, and the final value averages five independent executions.Source: §4.2.1 · p. 6
  • HPL’s matrix size, block size, and process grid are tuned per platform, while its solving-strategy parameters remain identical across systems.The matrix uses about 70% of available memory, and the block size is selected through full-node sweeps.Source: §4.2.1 · p. 6, Table 4 · p. 7, Table 5 · p. 7
  • HPCG uses a strong-scaled 384^3-cell problem of about 56 million unknowns, sized so its working set remains larger than cache.HPL-MxP uses FP32 factorization followed by FP64 iterative refinement, with the same mixed-precision scheme across platforms and OpenBLAS back ends.Source: §4.2.1 · p. 7

4.2.2. Applications

  • iPIC3D runs in sorted mode on a fixed 256 × 256 grid, while PLUTO strong-scales a fixed 336^3-cell Orszag–Tang problem for 10 steps.iPIC3D’s particle interactions are memory-bound; PLUTO’s stencil and Riemann-solver work is compute-bound and can benefit from SIMD vectorization.Source: §4.2.2 · p. 8
  • OpenFOAM is tested on one roughly 6.3-million-cell Windsor Squareback case; its sparse operations are scalar within each core, while parallelism uses MPI.llama.cpp tests GPT-OSS-20B with FP16 weights, 2,048-token prompts, 512 generated tokens, and batch sizes from 1 to 512.Source: §4.2.2 · pp. 8–9

5. Results

The results compare raw performance or time-to-solution, scaling from a single-core baseline, and energy use or efficiency across platforms.

5. Results

  • Performance is reported as raw throughput or time-to-solution, depending on the application.Reported runs use the best process-pinning strategy unless otherwise indicated.Source: §5 · p. 9
  • Scalability is measured as speedup relative to the single-core result, through each platform’s maximum core count.Source: §5 · p. 9
  • For equal-size, timed workloads, energy is total consumption in kJ; for sustained-performance tests, efficiency is performance per joule.The efficiency units are GFLOP/J or tok/J, as applicable.Source: §5 · p. 9

5.1. Synthetic Benchmarks

The synthetic benchmarks show substantial RISC-V generational gains, while the SG2044 remains behind Arm and x86 in absolute throughput. Its scaling varies by workload: memory bandwidth saturates beyond 16 cores, whereas HPCG and HPL-MxP show strong relative scaling.

5.1.1. STREAM

  • L2-cache-aware placement gives SG2044 STREAM bandwidth near-ideal scaling to 16 cores (12.6×), but only 13.5× at 64 cores as bandwidth gains become marginal.Distributing active cores across its 16 clusters scales better than concentrating them within one cluster.Source: §5.1.1 · p. 9, Figure 3 · p. 10
  • Across Monte Cimone generations, SG2044-based MCv3 reaches 107.0 GB/s aggregate memory bandwidth, compared with 1.1 GB/s for MCv1 and 52.4 GB/s for MCv2.The SG2044 has 7.8 GB/s single-core bandwidth; its absolute bandwidth remains below the Intel and NVIDIA reference systems.Source: §5.1.1 · p. 9, Figure 2 · p. 10

5.1.2. HPL

  • At 64 cores, SG2044 reaches 294 GFLOP/s in HPL, but remains far below Grace at 1,998 GFLOP/s and Sapphire Rapids at 4,209 GFLOP/s.SG2044 scales near-linearly to 16 cores before scaling increasingly deviates from ideality.Source: §5.1.2 · p. 11, Figure 4 · p. 11

5.1.3. HPCG

  • At 64 cores, SG2044 reaches 7.02 GFLOP/s in HPCG with 51.5× speedup, narrowing the single-core performance gaps to 11.0× versus Grace and 7.6× versus Sapphire Rapids.The fixed problem size is 40.5 GB; SG2044 peaks at 7.22 GFLOP/s and 94.5% efficiency on 56 cores.Source: §5.1.3 · p. 11, Figure 5 · p. 12

5.1.4. HPL-MxP

  • At 64 cores, SG2044 reaches 536.55 GFLOP/s in HPL-MxP with 36.90× speedup, remaining 12.27× and 12.41× behind Grace and Sapphire Rapids in absolute performance.RISC-V overtakes Sapphire Rapids in speedup at 64 cores, while Grace has the overall best speedup.Source: §5.1.4 · p. 12, Figure 6 · p. 12

5.2. Applications

Across the applications, SG2044 often delivers strong relative scaling despite lower absolute performance than the Arm and x86 systems. In llama-bench text generation, it provides the highest relative scaling and exceeds Intel in throughput at 64 cores.

5.2.1. iPIC3D

  • At 64 cores, SG2044 reaches 59.967 s in iPIC3D with 48.3× speedup, close to Grace’s 49.4×, but remains 15.0× slower than Grace in absolute time.Grace continues scaling to 128 cores and reaches a final time-to-solution of 2.578 s.Source: §5.2.1 · pp. 12–13, Figure 7 · p. 13

5.2.2. PLUTO

  • At 64 cores, SG2044 reaches 296 s in PLUTO with 51.4× speedup and 80.3% efficiency, while remaining 11.1× slower than Grace and 8.4× slower than Sapphire Rapids.At 32 cores, SG2044 has 30.1× speedup and 94.1% efficiency, exceeding both comparison platforms’ speedups.Source: §5.2.2 · p. 13, Figure 8 · p. 13

5.2.3. OpenFOAM

  • At 64 cores, SG2044 reaches 284.84 s in OpenFOAM with 38.74× speedup and 60.5% efficiency, while remaining 7.57× slower than Grace and 5.65× slower than Sapphire Rapids.Its fastest run is at 56 cores (274.95 s); the authors attribute early superlinear scaling to shrinking subdomains fitting into cache.Source: §5.2.3 · p. 14, Figure 9 · p. 14

5.2.4. llama.cpp–llama-bench

  • At 64 cores, SG2044 reaches 17.4 tok/s in llama-bench text generation with 22.1× speedup, exceeding Intel’s 14.0 tok/s and 6.1× speedup.Grace reaches 50.9 tok/s and 15.7× speedup; text generation is primarily memory-bandwidth constrained.Source: §5.2.4 · pp. 14–15, Figure 10 · p. 15

5.3. Energy efficiency

SG2044 energy efficiency is competitive with or better than Sapphire Rapids on several workloads, while it generally trails Grace. Frequency capping affects compute-bound prompt processing and memory-bound text generation differently.

5.3. Energy efficiency

  • SG2044 is more energy efficient than Sapphire Rapids in HPL-MxP, OpenFOAM, and llama-bench text generation, and reaches 0.209 tok/J in text generation at 64 cores.It generally has lower energy efficiency than Grace, but reaches 1.20 tok/J in prompt processing and 0.209 tok/J in text generation, versus Grace’s 1.14 and 0.159 tok/J.Source: §5.3 · p. 15, Figure 11 · p. 16
  • Across Monte Cimone generations, node-level energy efficiency rises from 0.315 GFLOP/J on MCv1 to 3.16 GFLOP/J on MCv3, a 10× improvement.FP64 performance rises from 1.86 to 294 GFLOP/s, a 158× improvement.Source: §5.3 · p. 15, Figure 11 · p. 16

5.3.1. Frequency capping

  • Capping CPU frequency decreases energy efficiency for compute-bound prompt processing, but improves it for memory-bound text generation, particularly at 1.9 GHz.The capped text-generation efficiency remains below that of the RISC-V and Arm platforms.Source: §5.3.1 · pp. 15, 17, Figure 11 · p. 16

6. Conclusions

The SG2044 remains 8–15× behind Intel and NVIDIA in absolute performance across classical HPC workloads, yet shows competitive scaling and energy efficiency on several workloads. Its results mark substantial progress over earlier RISC-V generations while pointing to compute, memory, technology, and software improvements for narrowing the gap.

6. Conclusions

  • 8–15× lower absolute performance than Intel and NVIDIA across classical HPC workloads, despite competitive scaling and energy efficiency on several workloads.The SG2044 exceeds Grace in 64-core llama-bench tests and markedly improves over previous Monte Cimone generations.Source: §6 · p. 17
  • The SG2044’s per-core performance and system resources support competitive scaling in HPCG, PLUTO, OpenFOAM, and LLM inference, with energy efficiency comparable to Intel across several workloads.It exceeds Grace in 64-core llama-bench tests.Source: §6 · p. 17
  • Higher compute throughput and vector capability, greater aggregate memory bandwidth, a more advanced technology node, and continued software and library optimization are identified as routes to reduce the performance gap.The Monte Cimone generations suggest these developments can progressively reduce the gap while preserving the open ISA’s flexibility.Source: §6 · p. 17

Related papers

Loading 2610.32632v2…