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

Toward Open ISA Supercomputing: A Comparative Study of RISC-V, Arm, and x86 Architectures on HPC Workloads ⋆ Emanuele Venieria,∗ , Giacomo Madellaa , Gabriele Ceccolinia , Simone Manonia , Federico Ficarellib , Filippo Barbarib , Jenny Lynn Almerolc , Elisabetta Boellad , Nitin Shuklab , Simone Bnàb , Luca Beninia,e and Andrea Bartolinia a University of Bologna, Bologna, Italy b CINECA, Casalecchio di Reno, Italy c University of Trento, Trento, Italy d E4 Computer Engineering, Scandiano, Italy

arXiv:2610.32632v1 [cs.DC] 23 Oct 2026

e ETH, Zurich, Switzerland

ARTICLE INFO

ABSTRACT

Keywords: HPC RISC-V ARM x86-64 SG2044 Energy Efficiency

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 scientific and industrial 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 100×, 158×, and 10×, respectively, over MCv1. Against the Arm and x86 systems, the SG2044 shows 8-15× 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 current RISC-V processors are closing the gap with the competition among diverse HPC workloads.

1. Introduction The open-source instruction set architecture (ISA) RISCV has seen remarkable growth in recent years, evolving from a research-oriented initiative into a promising alternative to established proprietary ISAs [1, 2]. Its open and modular specification has attracted contributors from academia, startups, and established semiconductor vendors, accelerating the pace of hardware innovation and software ecosystem maturation [1]. As implementations have become more capable and toolchain support has improved, RISC-V platforms have progressed well beyond microcontroller-class devices, giving rise to Linux-capable processors, multi-core system-on-chip (SoC), and accelerators targeting vector processing [3, 4], artificial intelligence (AI) [5], and scientific computing workloads. Compiler and runtime support have ⋆

This document is the results of the research project funded by the DARE (g.a. 101143421) project, the Italian Research Center on High Performance Computing, Big Data, and Quantum Computing, as well as the FUTURE research project. E.B. and N.S. acknowledge support from the SPACE project, funded by the European Union (g.a. 101093441). ∗ Corresponding author emanuele.venieri2@unibo.it (E. Venieri) ORCID (s): 0009-0007-7182-505X (E. Venieri)

E. Venieri et al.: Preprint submitted to Elsevier

advanced substantially, with mainstream toolchains such as GCC and LLVM providing full RISC-V backends and vectorization support, while HPC libraries and programming models such as OpenMP, MPI and BLAS are increasingly being ported and optimized for the architecture [1, 2]. This convergence of open hardware and software ecosystems made it feasible to consider RISC-V as an emerging target platform within the context of high-performance computing (HPC) [1, 2, 6–8], a field traditionally dominated by Intel’s x86 and, more recently, Arm architectures [9]. In recent years, many research efforts have evaluated Arm and x86 systems for parallel and scientific computing [9–16], and more recently RISC-V to a limited extent [1, 2, 11, 17–19]. Nevertheless, the existing body of work remains fragmented, as prior studies generally evaluate only one or two processor families and often focus on limited benchmark suites, individual applications, or specific architectural aspects, making direct cross-architecture comparisons difficult. More critically, while power consumption and thermal envelopes represent primary constraints in modern supercomputing, existing comparative evaluations largely overlook comparative energy and power-efficiency analyses, often omitting metrics such as energy-to-solution Page 1 of 18

Toward Open ISA Supercomputing

or performance-per-watt across real-world codes. Consequently, a unified characterization of contemporary HPCoriented processors spanning x86, Arm, and RISC-V under a common evaluation methodology remains largely unexplored, preventing a clear understanding of where HPC RISC-V currently stands compared with mature commercial architectures. To enable a fair and meaningful comparison, this work adopts a consistent experimental methodology across all evaluated platforms. We employ the same compiler toolchain, software libraries, and programming environments whenever possible, while enabling architecture-specific optimizations only when they are mature, publicly available, and representative of real-world usage. The evaluation covers a broad spectrum of HPC-relevant workloads, including synthetic benchmarks, and representative scientific and AI applications. Specifically, we evaluate STREAM [20], HPL [21], HPL-MxP [22], HPCG [23], iPIC3D [24], PLUTO [25], OpenFOAM, [26] [27] and Llama.cpp [28]. These workloads cover a broad range of computational characteristics, allowing us to characterize memory bandwidth, dense and sparse linear algebra, low-precision computing, and realworld scientific simulations in plasma physics, astrophysics, and computational fluid dynamics, as well as emerging AI inference workloads on general-purpose processors. Together, these workloads provide a broad view of computational throughput, scalability, memory behavior, and energy efficiency across different architectures. In summary, this paper presents an extensive experimental study of contemporary RISC-V processors and their position within the HPC ecosystem. The main contributions of this work are as follows: • We provide an extended characterization of the most powerful general purpose, HPC-grade RISC-V CPU chip currently available in the market: the Sophgo SG2044. We covered its architectural features, memory subsystem, scalability across 64 cores, and energy efficiency under HPC-relevant workloads. The SG2044 achieves 7.8 GB/s of single-core memory bandwidth and 8.02 GFLOP/s of FP64 performance, reaching 107 GB/s and 294 GFLOP/s, respectively, at 64 cores. L2-cache-aware process pinning improves scaling, reaching twice the bandwidth at 16 cores and revealing memory-bandwidth saturation beyond that core count. • We analyze the evolution of RISC-V HPC platforms within the Monte Cimone (MC) research project [1, 17], providing a cross-generational perspective on architectural improvements and their impact on HPC workloads. Compared with MCv2, the SG2044based MCv3 doubles both the available peak memory bandwidth and single-core performance. Relative to MCv1, memory bandwidth, per-node FP64 performance, and energy efficiency improve by approximately 100×, 158×, and 10×, respectively. E. Venieri et al.: Preprint submitted to Elsevier

• We perform a comparison of the SG2044 with HPCclass processors, namely the Arm-based NVIDIA Grace CPU Superchip and the x86-based Intel Xeon Platinum 8480+. While the SG2044 remains 8-15× behind in absolute performance for several workloads, it achieves competitive or superior scaling in multiple cases while maintaining comparable energy efficiency. In particular, for LLM inference decode, the SG2044 at 64 cores achieves the highest relative scaling (22.2× vs. 15.7× and 6.1×) and energy efficiency among the evaluated platforms (0.209 tok/J vs. 0.159 tok/J and 0.017 tok/J), while also providing higher throughput than the Intel platform (17.4 tok/s vs. 14.0 tok/s). • We identify architectural characteristics that influence the competitiveness of current RISC-V processors for HPC, highlighting both their strengths and remaining limitations. For compute-bound workloads such as HPL, the normalized single-core performance of the evaluated platforms follows a trend consistent with the relative width of their vector units, suggesting that increased vector width represents one potential direction for improving single-core performance in future RISC-V HPC processors. • HPL-MxP OpenBLAS implementation: we provide an open-source, ready-to-use implementation of HPLMxP based on the official reference code and linked against OpenBLAS, offering a simple and portable solution that can be readily deployed on generic CPUbased systems, without relying on platform-specific or vendor-optimized implementations. The remainder of this paper is organized as follows. Section 2 describes the context of our evaluation. Section 3 describes the hardware platforms and their relevant architectural characteristics. Section 4 presents the evaluated benchmarks and applications, together with the experimental methodology adopted for the analysis. Section 5 reports and discusses the experimental results, including performance, scalability, and energy-efficiency comparisons across the evaluated architectures. Finally, Section 6 summarizes the main findings and discusses future research directions.

2. Related Works In recent years, several studies [10, 12–15] have investigated the evolution of HPC processors beyond the traditional x86 ecosystem, with particular attention to Arm-based alternatives.

2.1. Arm and x86 HPC Characterization Jackson et al. [13] provided one of the first evaluations of Arm for HPC, showing that Arm systems could achieve competitive performance with established x86 platforms and proving its maturity. More recent works evaluated newer generations of Arm processors, including cloud-oriented systems and HPCfocused designs. Simakov et al. [12] compared ARM systems Page 2 of 18

Toward Open ISA Supercomputing

such as AWS Graviton2/3, Fujitsu A64FX, Ampere Altra, and ThunderX2 against Intel and AMD x86 platforms using HPC benchmarks and scientific applications. They found that modern Arm systems can achieve competitive performance and often higher energy efficiency than x86, although the advantage depends strongly on workload characteristics: memory-bandwidth-bound applications benefited from Arm’s high core counts and efficient memory subsystems, while workloads relying on optimized x86 libraries or higher floating-point throughput favored x86 processors. The recent introduction of NVIDIA Grace CPU Superchip has further increased interest in Arm for HPC-class systems. Simakov et al. [14] evaluated Grace using HPCC, HPCG, and scientific applications including GROMACS, OpenFOAM, and ROMS, comparing it with Intel and AMD systems. They showed that Grace can achieve competitive node-level performance thanks to its high core count and memory subsystem, matching or exceeding selected x86 systems in several workloads while remaining behind in others. From a microarchitectural perspective, Laukemann et al. [15] compared Arm Neoverse V2, Intel Sapphire Rapids, and AMD Genoa through in-core modeling and microbenchmarks, analyzing execution throughput, memory behavior, and architectural features affecting performance. Similarly, Banchelli et al. [10] investigated power efficiency differences between Grace and Sapphire Rapids using STREAMlike and floating-point microbenchmarks, reporting up to 3.25× higher power efficiency for Grace in selected kernels. While these evaluations primarily compare the established x86 and Arm ecosystems, the emergence of RISC-V introduces a new dimension. Its open ISA, extensible architecture, and growing community support position RISC-V as a promising candidate for future HPC systems.

2.2. RISC-V Evaluation for HPC Compared with ARM and x86, RISC-V represents a relatively young ecosystem in HPC. Although several highperformance RISC-V platforms have been announced by major vendors, the Sophgo SG2042 and its successor, the SG2044, are currently the only commercially available processors targeting this market. Recent studies [2, 7, 11, 18, 19, 29, 30] have investigated their potential from different perspectives, including synthetic benchmarks and scientific applications. A first class of works focuses on synthetic benchmarks and architectural characterization. Gomez et al. [18] investigated long-vector architectures for HPCG, including RISCV vector extensions, proposing optimized implementations of the benchmark kernels. Their evaluation demonstrated that RISC-V vector architectures can effectively exploit memory bandwidth and achieve promising performance for HPCG-like workloads. However, the evaluated RISCV platform was the European Processor Initiative (EPI) EPAC experimental accelerator rather than a commercially available processor, limiting the direct applicability of the results to production HPC systems. Similarly, Lazzeri et

E. Venieri et al.: Preprint submitted to Elsevier

al. [19] evaluated several RISC-V processors using CoreMark, Geekbench 6, and SPEC CPU2017, highlighting the progress of recent commercial implementations while showing that a substantial performance gap still exists with respect to contemporary high-end Arm and x86 processors. Collectively, these studies provide valuable insights into specific architectural characteristics, such as vectorization capabilities, memory behavior, and processor efficiency, but rely primarily on synthetic benchmark suites rather than representative HPC workloads. Complementary efforts have instead considered application oriented evaluations. Suarez et al. [11] compared Arm and RISC-V SoCs using performance and energy measurements, employing OpenFOAM as a representative computational fluid dynamics application. While the study highlighted the energy-efficiency potential of RISC-V implementations, the evaluated systems targeted embedded-class platforms rather than HPC-oriented processors. More recently, Garcia et al. [29] investigated RISC-V vector extensions for large language model inference on the commercially available Sophgo SG2042 CPU, showing that RVV can accelerate inference by up to 1.3× depending on workload characteristics while also exposing current software ecosystem limitations. Although these works demonstrate the applicability of RISC-V to real applications, they remain focused on individual application domains and do not provide a broader characterization across the diverse workload spectrum encountered in HPC. Finally, recent efforts have started evaluating complete server-class RISC-V platforms. Brown [2] presented the first characterization of the Sophgo SG2044 processor through STREAM and NAS Parallel Benchmarks, comparing it with AMD EPYC, Intel Skylake, and Arm ThunderX2 systems. The study highlighted the substantial improvements of the SG2044 memory subsystem and its scalability compared with the previous SG2042 generation. However, its evaluation primarily focused on micro-benchmarks and pseudoapplications, without an in-depth analysis of the SG2044’s UMA architecture or its behavior across a broader set of realworld HPC applications.

2.2.1. The Monte Cimone Project Complementing these efforts, the Monte Cimone project [1, 17] hosted at University of Bologna’s DEI department in collaboration with CINECA and E4 Computer Engineering, has progressively explored the adoption of RISC-V for HPC through successive generations of clustered hardware. Initially conceived as a hardware–software co-design platform, Monte Cimone has evolved into a research infrastructure for evaluating increasingly capable server-class RISC-V processors and their supporting software ecosystem. The platform integrates HPC-oriented components, including the SLURM job scheduler, EXAMON system monitoring, shared home directories, and environment modules for consistent software deployment across nodes. This infrastructure has supported research spanning RISC-V software porting and optimization [1, 31–33]. The successive generations therefore Page 3 of 18

Toward Open ISA Supercomputing

C0

C1

C2

C3

C0

C1

C2

C3

C4

C5

C6

C7

C4

C5

C6

C7

C8 C9 C10 C11 L3 (105 TB) C12(105 C13 L3 TB)C14 C15 LPDDR5 (1 TB)TB) L3 (105 LPDDR5 (1 TB) L3 (105 MB) LPDDR5 (1 TB) LPDDR5 (251 GB)

C8 C9 C10 C11 L3 (105 TB) C12(105 C13 L3 TB)C14 C15 LPDDR5 (1 TB)TB) L3 (105 LPDDR5 (1 TB) L3 (105 MB) LPDDR5 (1 TB) LPDDR5 (251 GB)

Intel Sapphire Rapids

MAT (AMX) VEC 512b (AVX) FP INT ROB: 512-entries Ret: 8-wide Disp: 8-wide Dec: 6-wide L1-I$ (32 kB) L1-D$ (48 kB) L2 (2048 kB)

Table 1 Hardware characteristics of the evaluated platforms.

VEC 128b (SVE2) FP INT ROB: 320-entries* Ret: 8-wide Disp: 8-wide Dec: 5-wide L1-I$ (64 kB) L1-D$ (64 kB) L2 (1024 kB)

VEC 128b (RVV1.0) FP INT ROB: N/A Ret: N/A Disp: N/A Dec: N/A L1-I$ (64 kB) L1-D$ (64 kB)

C0

C1

C4

C5

C8

C9

C12 C12

C2

C3

C6

C7

C10 C11

C14 C15

L2 (2MB)

L2 (2MB)

L2 (2MB)

L2 (2MB)

C16 C17

C20 C21

C24 C25

C28 C29

C18 C19

C22 C23

C26 C27

C30 C31

L2 (2MB)

L2 (2MB)

L2 (2MB)

L2 (2MB)

C32 C33

C36 C37

C40 C41

C44 C45

C16 C17 C18 C19 C20 C21 C22 C23

C34 C35

C38 C39

C42 C43

C46 C47

C24 C25 C26 C27 C28 C29 C30 C31

L2 (2MB)

L2 (2MB)

L2 (2MB)

L2 (2MB)

C32 C33 C34 C35 C36 C37 C38 C39

C48 C49

C52 C53

C56 C57

C60 C61

C50 C51

C54 C55

C58 C59

C62 C63

C56 C57 C58 C59 C60 C61 C62 C63

L2 (2MB)

L2 (2MB)

L2 (2MB)

L2 (2MB)

C64 C65 C66 C67 C68 C69 C70 C71 240GB LPDDR5X L3 (114 MB)

C0

C1

C2

C3 C4

C5

C6

C7

C8

C9 C10 C11 C12 C13 C14 C15

C40 C41 C42 C43 C44 C45 C46 C47

L3 (64 MB)

C48 C49 C50 C51 C52 C53 C54 C55

LPDDR5X (128 GB)

LPDDR5X (471 GB)

Sophgo SG2044

NVIDIA Grace CPU Superchip

Figure 1: Overview of the three server-class processors evaluated in this work. The figure compares the Intel Xeon Platinum 8480+ (Sapphire Rapids), NVIDIA Grace CPU Superchip, and Sophgo SG2044 architectures, highlighting their core organization, cache hierarchy, vector execution capabilities, memory subsystem, and node-level configuration.

provide a longitudinal view of RISC-V evolution in HPC while serving as a reusable platform for developing and evaluating the associated software stack. Overall, existing studies have significantly advanced the understanding of RISC-V for HPC from architectural, application, and system-level perspectives. Nevertheless, the current literature remains fragmented across different processor generations, benchmark suites, and application domains. As a result, it is still difficult to assess the current position of RISC-V within the HPC processor landscape, particularly with respect to contemporary x86 and Arm server-class processors. A cross-ISA characterization based on modern representatives of the three ecosystems, evaluated under a common experimental methodology and across a broad spectrum of synthetic, scientific, and AI workloads, is still missing.

3. Systems and Platforms To assess the current state of RISC-V for HPC, we compare representative server-class processors from the three SoA major CPU ecosystems: x86, Arm, and RISC-V. The evaluated systems are all commercially available platforms, avoiding comparisons against experimental prototypes or pre-production hardware. For the proprietary ISAs, we select Intel Sapphire Rapids and NVIDIA Grace, as they represent two of the most relevant server processors currently E. Venieri et al.: Preprint submitted to Elsevier

ISA Cores / Node Vector ISA Vector length Technology node Max Frequency [GHz] Memory channels Memory Type Memory NUMA

SG2044 RISC-V 64 RVV 1.0 128 bits TSMC 12nm 2.6 32 LPDDR5X 128 GB No

Intel SR x86-64 112 (2×56) AVX-512 2×512 bits Intel 7 3.8 16 DDR5 2 TB Yes

NVIDIA GS Armv9 144 (2×72) SVE2 4×128 bits TSMC 4N 3.3 32 LPDDR5X 960 GB Yes

deployed in HPC systems. Sapphire Rapids is the most widely deployed Intel processor generation in the June 2026 TOP500 list, powering 84 systems (16.8% of the ranked machines), while NVIDIA Grace is the most widely deployed Arm processor in the same list, appearing in 25 systems (5%) [34]. Grace also represents NVIDIA’s latest Arm-based CPU architecture specifically designed for HPC and AI workloads. For RISC-V, we evaluate the Sophgo SG2044, which is currently the most advanced commercially available highcore-count server processor based on the RISC-V ISA [1, 2]. This selection enables a meaningful assessment of the current position of RISC-V with respect to the highestperformance commercially available processors from the established x86 and Arm ecosystems.

3.1. Architectural Overview The main architectural characteristics of the evaluated platforms are summarized in Fig. 1 and described below.

3.1.1. Intel Xeon Platinum 8480+ (Intel SR): a Sapphire Rapids generation x86_64 processor. Official Intel documentation describes the ISA features and cache hierarchy, whereas front-end characteristics (6wide decode, 8-wide dispatch and retirement, and a 512entry reorder buffer) follow publicly available microarchitectural analyses [35, 36]. Each Golden Cove core integrates AVX-512 vector extensions and Intel Advanced Matrix Extensions (AMX), together with private 48 KB L1 data and 2 MB L2 caches. The evaluated system consists of two sockets which each of them comprises four Compute Tiles interconnected through Intel’s on-chip mesh, exposing four NUMA domains and sharing a 105 MB L3 cache. Each tile physically integrates 16 cores, of which one serves as a memory core, while one additional core per socket is inactive due to silicon manufacturing defects (highlighted in red and white, respectively, in Fig. 1), resulting in 56 usable cores per socket (112 in total). Hyper-Threading was disabled throughout the experiments and frequency scaling governor set to performance to ensure a consistent comparison across architectures and to focus the analysis on physical-core performance. 3.1.2. NVIDIA Grace CPU Superchip (NVIDIA GS): a dual-socket Armv9 platform comprising two 72-core processors, for a total of 144 Neoverse V2 cores. Official Arm and NVIDIA documentation describe Page 4 of 18

Toward Open ISA Supercomputing

the processor architecture, cache hierarchy, and SVE2 ISA support, whereas front-end characteristics (6-wide decode, 8-wide dispatch, 8-wide retirement, and a 320-entry reorder buffer) follow the values reported in [37]. Each core provides private 64 KB L1 data and 1 MB L2 caches, while a 114 MB L3 cache is shared by the 72 cores within each die. The two Grace dies form two NUMA domains connected through the NVLink-C2C interconnect, resulting in non-uniform memory access between the two sockets.

3.1.3. Sophgo SG2044 (SG2044): a 64-core RISC-V processor implementing the RV64GCV ISA with RVV 1.0 vector support. The processor is composed of 16 four C920V3 core clusters. The C920V3 core features a 12-stage out-of-order pipeline with a 4-wide issue width and a 10-wide execution architecture, as reported by the IP manufacturer [38]. Each core provides a private 64 KB L1 data cache, while groups of four cores share a 2 MB L2 cache and all cores share a 64 MB L3 cache. Unlike the x86 and Arm platforms, the SG2044 exposes a Uniform Memory Access (UMA) architecture, in which all cores observe approximately the same latency when accessing any region of the 128 GB LPDDR5X main memory. The processor is deployed within the Sophgo RISC-V Compute Server SRA3-40 platform [39]. The main characteristics of each platform are summarized in Table 1.

4. Evaluation Methodology The methodology adopted in this work is designed to minimize software-induced variability across the evaluated platforms, enabling a more direct assessment of performance differences attributable to architectural and systemlevel characteristics. To this end, we rely on widely available, community-supported software stacks and apply the same compiler toolchains, libraries, and runtime configurations whenever possible. Vendor-specific benchmark suites or proprietary optimizations that could introduce unfair advantages are avoided; however, mature and publicly available optimizations required to fully exploit each architecture (e.g., vector instruction support and optimized numerical libraries) are enabled when representative of HPC practice. To establish a consistent experimental baseline, all systems run the Linux kernel 6.12 and use GCC 14.2 as the reference compiler. The Message Passing Interface (MPI) layer is provided by OpenMPI 5.0 across all platforms. As a reference high-performance linear algebra library, OpenBLAS 0.3.34 is employed, compiled with architecture-specific optimization flags as reported in table 2. This configuration is used for all relevant benchmarks, including dense linear algebra workloads such as HPL. To obtain power measurements, we first collected all available sensor data from the evaluated systems through the ExaMon [40] infrastructure. On x86 and Arm nodes, IPMI telemetry was used to measure total node power consumption and fan speed. In addition, architecture-specific mechanisms were exploited where available: Running Average Power Limit (RAPL) on the Intel Sapphire Rapids E. Venieri et al.: Preprint submitted to Elsevier

Table 2 OpenBLAS compilation target parameter for each machine Machine SG2044 Intel SR NVIDIA GS

TARGET parameter RISCV64_ZVL128B SAPPHIRERAPIDS NEOVERSEV2

and hardware monitoring (hwmon) on NVIDIA Grace were used to collect processor-level power measurements. A key difference concerns the RISC-V SG2044, IPMI reports only board-level power and excludes fans and other auxiliary components. We therefore engineered combined power metrics by modeling the power consumption of fans and auxiliary components for each architecture and combining these models with RAPL and hwmon measurements, allowing us to isolate board-level power and define a common power domain across all platforms.

4.1. NUMA aware process pinning For each benchmark, we ran experiments on processto-core pinning, aiming to find an optimal placement that reflects the machine’s memory topology and to characterize the differences with respect to other strategies. In Table 3 we summarize the adopted pinning strategies. On SG2044, which is a UMA machine, the l2_cache_aware strategy generally proved to be the best. By distributing processes evenly across the 16 L2 clusters, saturation of the L2 caches is delayed, allowing the workload to benefit longer from the higher aggregate L2 bandwidth. Once saturation is reached, the advantage shrinks and becomes equivalent to the sequential strategy. On Grace, the best strategy is to alternate process pinning across both NUMA nodes (the two dies), so that all of the chip’s memory controllers are engaged from the start, fully exploiting the bandwidth available to the whole system. On Sapphire Rapids, similarly to Grace, the numa_aware_distributed strategy proved to be the best. Overall, we found that on our NUMA platforms it is preferable to use all available bandwidth from the start, even at the cost of placing processes on different NUMA nodes, thus paying the higher latency of inter-process MPI communication across NUMA node boundaries. On the UMA machine, however, it is still worth balancing processes across the L2 clusters, so as to avoid prematurely saturating the L2 caches.

4.2. Benchmark Suite and Applications As evaluation software, we combine synthetic benchmarks with real-world applications operating on comparable data formats and computational primitives to provide a balanced characterization of both peak performance and system-level behavior. Synthetic benchmarks isolate specific architectural characteristics, such as floating-point throughput, memory bandwidth, and energy efficiency, while application level workloads provide a representative assessment of end-to-end performance across scientific simulations and AI workloads. The specific parameters used for each test Page 5 of 18

Toward Open ISA Supercomputing Table 3 Thread/process placement policies. Platform All SG2044 Grace Sapphire Rapids

Policy os_default sequential l2_cache_aware dual_die_interleaved numa_aware_distributed numa_aware_local strict_numa_local strict_numa_distributed

Description OS scheduler free to migrate processes. processes pinned in raw core order (0, 1, 2, ...) (best) round-robin across all 16 L2 clusters, stride 4 (0, 4, 8, 12, ...). (best) round-robin between the two dies (0, 72, 1, 73, ...). caps total bandwidth to one die. (best) balancing processes across NUMA nodes on both sockets. fills socket 0’s physical cores first, then socket 1 (0, 2, 4, ..., 110, 1, 3, ..., 111) fills one NUMA node completely before the next, socket 0 first then socket 2. fills one NUMA node of socket 0, then one of socket 1, alternating.

are described in the corresponding sections. We evaluate strong scaling: for a given problem size, the workload is kept constant while increasing the number of active cores. This allows us to assess how effectively each platform exploits additional compute resources for the same computational problem.

4.2.1. Synthetic Benchmarks The synthetic benchmark suite includes the components explained in the following paragraphs.

STREAM: Evaluates the sustainable memory bandwidth

of a system using four fundamental vector operations (Copy, Scale, Add, and Triad) executed over large, contiguous data arrays [20]. Unlike compute-bound workloads, STREAM is heavily memory-bound, featuring an arithmetic intensity near zero with 𝑂(𝑁) computational complexity scaling directly with 𝑂(𝑁) data movement. Performance is reported as sustained memory bandwidth in gigabytes per second (GB/s) for each kernel. The benchmark is configured according to the general recommendations provided in the official STREAM guidelines. Since our objective is to characterize main-memory performance, we set STREAM_ARRAY_SIZE to 120,000,000, resulting in 960 MB per array when using double-precision elements. The selected size ensures that the STREAM working set substantially exceeds at least four times the Last-Level Cache (LLC) capacity of all evaluated systems, thereby minimizing the influence of cache effects on the measured memory bandwidth. The NTIMES parameter is kept at its default value of 10. Consequently, each STREAM execution performs 10 timed repetitions, with the best result reported by the benchmark. At a higher level, our measurement pipeline executes each experiment five independent times. The final reported value is the average across these five executions, with the corresponding variability reported as the measurement error. Among the STREAM kernels evaluated, in section 5.1.1 we report the Triad kernel as the representative case in this analysis. The remaining STREAM kernels were also evaluated and showed consistent qualitative trends; therefore, to avoid redundancy, only Triad results will be discussed.

dense linear system 𝐴𝑥 = 𝑏 through LU factorization with partial pivoting (𝑃𝐴 = 𝐿𝑈 ) [21]. Computation is performed in 64-bit floating-point (FP64) and is dominated by the 𝑂(𝑁 3 ) matrix-matrix multiplication kernel (DGEMM), making standard HPL a compute-bound workload and a reference benchmark for evaluating sustained peak throughput (𝑅max ) expressed as performance in GFLOP/s. In our evaluation, we utilize the reference HPL 2.3 implementation linked against OpenBLAS (v0.3.34) and using a MPI rank per core. HPL exposes two main classes of configuration parameters. The first defines the problem geometry and parallel decomposition, including the global matrix size (𝑁), block size (𝑁𝐵), and two-dimensional process grid (𝑃 × 𝑄). These parameters directly affect load balancing, communication overhead, and cache utilization, and were experimentally tuned on each platform to maximize sustained performance. The second class controls the solving strategy and to ensure a fair comparison across architectures, these algorithmic parameters were kept identical for all experiments, as summarized in Table 4. Following the HPL recommendations, 𝑁 was selected to use approximately 70% of available memory and rounded to the nearest multiple of 𝑁𝐵. The block size was empirically selected through full-node sweeps over 𝑁𝐵 = 64–512. The process grid follows the HPL recommendation of a nearly square grid with 𝑃 ≤ 𝑄 and 𝑃 × 𝑄 = 𝑁MPI , and to match 𝑃 with the number of processors in multi-CPU systems. For NVIDIA Grace, 𝑃 = 2 was fixed to match its two interconnected CPUs, with 𝑄 adjusted to satisfy 𝑃 × 𝑄 = 𝑁cores . For Intel Sapphire Rapids, both 𝑃 = 2, matching the two CPUs, and 𝑃 = 8, matching the NUMA domains, were evaluated, with 𝑄 adjusted accordingly. Conversely, the RISC-V platform consists of a single-socket processor (𝑃 = 1), for which multiple executions at the maximum core count were performed to empirically determine the process-grid configuration yielding the highest performance. The final machine-dependent parameters are reported in Table 5.

HPCG: the High Performance Conjugate Gradient bench-

mark, complements HPL by evaluating sparse iterative computations that are representative of many scientific applications. It solves a synthetic sparse linear system arising

HPL: The High Performance Linpack benchmark mea-

sures sustained floating-point performance by solving a E. Venieri et al.: Preprint submitted to Elsevier

Page 6 of 18

Toward Open ISA Supercomputing Table 4 HPL.dat parameters. The first group was determined with ad hoc experiments. Category Tuned

Fixed

Parameter 𝑁 𝑁𝐵 𝑃 𝑄 PMAP Threshold PFACT NBMIN NDIV RFACT BCAST DEPTH SWAP Swap threshold L1 storage U storage Equilibration Memory alignment

Value function of memory size experimental experimental experimental Row-major 16.0 Left 2 2 Right 1-ring 0 Mix 64 Transposed Transposed Enabled 8 doubles

Table 5 HPL.dat machine-tuned parameters. Machine SG2044 Sapphire Grace

N 105792 418176 289792

NB 64 384 128

P 4 8 2

Q 16 14 72

from the discretization of a 3D problem using a preconditioned conjugate gradient solver with a geometric multigrid preconditioner [41]. Unlike HPL, HPCG is primarily limited by irregular memory accesses, data movement, and communication, making it representative of memorybound scientific workloads. Performance is reported as the sustained floating-point rate (GFLOP/s) during the timed execution. To evaluate scalability under a constant workload, all experiments employ a strong-scaling configuration. We use a global problem size of 3843 cells (approximately 56 million unknowns, corresponding to about 40.5 GB of data on a single process), which is evenly partitioned among the available MPI ranks. The local subdomain dimensions are adjusted as the number of ranks increases to keep the global problem approximately constant. This problem size was selected to ensure that, even at the highest core counts, the local working set remains significantly larger than the available cache capacity, so that the benchmark is primarily limited by the main memory subsystem rather than cache bandwidth.

HPL-MxP: A mixed-precision variant of the HPL bench-

mark designed to bridge the gap between traditional doubleprecision scientific workloads and the low-precision tensor capabilities of modern HPC hardware. To reconcile these divergent hardware trends, HPL-MxP combines modern mixed-precision algorithms with maximum hardware efficiency while maintaining direct numerical parity with

standard HPL [42]. The algorithm shifts the computationally dominant 𝑂(𝑁 3 ) LU factorization into a hardwaresupported reduced-precision format like FP16, BF16, or FP32. The resulting low-precision factors then serve as a preconditioner within an iterative refinement loop, typically using the Generalized Minimal Residual (GMRES) Krylov method, executed in full FP64 precision to recover standard ‖𝐴𝑥−𝑏‖ ≤ 𝑂(𝜀FP64 )). Efdouble-precision accuracy ( ‖𝐴‖‖𝑥‖+‖𝑏‖ fective throughput is reported in sustained FP64-equivalent FLOPS, defined by dividing the theoretical FP64 operation count (as defined in HPL) by the combined execution time of both the factorization and refinement phases. Due to the lack of a ready-to-use, multi-architecture solution, we created our own implementation 1 starting from the reference HPL-MxP code [22]. Specifically, we replaced its internal BLAS backend, including SGEMM, STRSM, DTRSM, and DGEMV, with the shared OpenBLAS library. This approach enabled us to leverage OpenMP without further editing the core algorithms, which we used to exploit parallelism, tailoring it on each architecture. For this same reason, to avoid deviating further from the original reference, we decided to step down only to FP32, implementing a dual-precision scheme based solely on FP64 and FP32. In accordance with the standard methodology for HPL and HPL-MxP benchmarks, which require stressing the system’s memory capacity to properly assess peak performance,we scale the problem size (N) to utilize at least 70% of the available memory on each platform. The computational workflow begins with the matrix and right-hand side generated in FP64, which are then downcast to FP32 for the core factorization phase. Finally, the results are cast back to FP64 for iterative refinement and validation. This mixed-precision scheme is kept strictly identical across all evaluated machines; only the architecture-specific OpenBLAS kernels and compiler optimization flags differ.

4.2.2. Applications The selected applications span a diverse set of computational domains and execution characteristics, enabling the evaluation of the architectures under representative HPC and AI workloads. Together, they cover a broad range of computational patterns, including particle-based simulations, stencil computations, computational fluid dynamics, and transformer-based inference. To ensure a fair comparison, identical input datasets, software versions, and compilation configurations are used across all evaluated platforms whenever possible.

iPIC3D: a semi-implicit Particle-in-Cell (PIC) code devel-

oped to simulate collisionless plasma dynamics at kinetic scales [24]. The code is written in C/C++ and parallelised via MPI. The simulation advances macro-particles in a Lagrangian framework while solving Maxwell’s equations and computing plasma moments, including charge density and current, on an Eulerian grid. The computational workload is dominated by particle pushing together with particle-to-grid 1 HPL-MxP

repository

used:

https://gitlab.com/ecs-lab/tools/

hpl-mxp-ecslab

E. Venieri et al.: Preprint submitted to Elsevier

Page 7 of 18

Toward Open ISA Supercomputing

and grid-to-particle interpolation. Particles are traversed in memory order, unrelated to their position in the domain, so unless they are sorted by cell, each particle’s interaction with a small, time-varying neighborhood of grid cells leads to irregular memory accesses and limited data reuse [43]. We run iPIC3D in its sorted mode, which groups particles by cell so that consecutive particles access neighboring grid data; this was the best-performing configuration in [44]. Overall, iPIC3D is largely memory-bound rather than compute-bound. The selected 2D simulation models the current filamentation instability, a typical plasma instability which leads to the amplification of the magnetic field in the direction out of the plane [45]. The computational domain is decomposed only along the 𝑥 and 𝑦 dimensions. For a given number of MPI ranks 𝑁, the process grid XLEN × YLEN is chosen as the factorization of 𝑁 closest to a square (XLEN ≤ YLEN and XLEN ⋅ YLEN = 𝑁), while ZLEN = 1. To ensure an even partitioning of the fixed 256 × 256 grid, both XLEN and YLEN must divide 256. Consequently, only rank counts satisfying this constraint are considered, resulting in strong-scaling experiments with 1, 2, 4, 8, 16, 32, and 64 MPI ranks (and 128 on the Grace system).

PLUTO: a C/C++ code for computational plasma as-

trophysics that solves the magnetohydrodynamics (MHD) equations with a finite-volume Godunov-type scheme on structured grids, computing interface fluxes via local Riemann solvers [25]. The computational workload is dominated by stencil-based updates and Riemann solver evaluations. These kernels involve intensive double-precision floating-point operations with structured memory access patterns, making the application largely compute-bound and able to benefit from SIMD vectorization. Parallel execution relies on MPI domain decomposition with halo exchanges between neighboring subdomains, whose cost becomes increasingly significant as the number of processes increases. We configure PLUTO with the Orszag–Tang vortex, a standard ideal-MHD test problem, discretized on a Cartesian grid of 3363 cells. The 336 = 24 ⋅ 3 ⋅ 7 admits balanced, near-cubic domain decompositions for every process count used in our sweeps. Since we are only interested in the periteration computational cost and not in the physical evolution of the vortex, each run is limited to a fixed number of 10 integration steps. We perform a strong-scaling study: the global grid is held fixed at 3363 cells while the process count is varied from 1 up to the full core count of each node.

OpenFOAM: a leading open-source Computational Fluid

Dynamics (CFD) framework widely used in scientific and engineering simulations. Parallelism is exploited exclusively at the MPI level, through domain decomposition and distribution of the resulting subdomains across cores, with interprocess communication at subdomain boundaries. It relies heavily on sparse linear system solvers and discretizations on unstructured grids, placing significant pressure on memory bandwidth and latency while also stressing inter-core communication in parallel executions. E. Venieri et al.: Preprint submitted to Elsevier

The tests conducted on OpenFOAM (v2512) were performed on a single case study, the Windsor Squareback geometry [46], which simulates an idealized vehicle profile in a wind tunnel and is used in the Automotive CFD Workshop (AutoCFD, Case 1) [47]. For practicality and computational/time-resource reasons, the smallest available mesh (grid 1) was chosen, consisting of approximately 6.3 million cells. Despite its modest size, this case study is qualitatively close to an industrial automotive CFD case, making it significant for this study. Domain decomposition across MPI processes is handled by the KaHIP graphpartitioning algorithm [48]. The case is run with simpleFoam, the incompressible finite-volume solver of OpenFOAM, which couples pressure and velocity through the SIMPLE algorithm [49]. Every configuration executes a fixed budget of 100 iterations, so that the amount of work is identical across architectures and core counts and the measured wall-clock times are directly comparable. Turbulence is modeled using the Reynolds-Averaged Navier–Stokes (RANS) approach. The dominant cost of each iteration is the solution of the pressure equation, with one unknown per cell (of the order of six million) and characterized by a large sparse linear system, solved with a geometric-algebraic multigrid method (GAMG) [50] using the Gauss-Seidel smoother [51]. In the upstream OpenFOAM version used here, all sparse matrix operations, rely on OpenFOAM’s native LDU-COO format. Designed for scalar execution, this format is ill-suited to vectorization because of irregular memory access and potential race conditions during result updates. Compiler auto-vectorization is thus limited to loops over dense arrays, whose cost is negligible. OpenFOAM is therefore highly parallel across cores via MPI, but strictly scalar within each core.

llama.cpp: a C++ implementation of large language model (LLM) inference optimized for CPU execution. It enables efficient execution of transformer-based models in environments without dedicated accelerators. While LLM inference is typically deployed on GPU-based systems in large-scale, high-throughput settings, CPU inference remains relevant for single-user or low-concurrency scenarios, particularly when large models must be executed within the constraints of memory capacity and without multi-GPU model parallelism. In these conditions, the absence of batching and high request concurrency shifts the performance bottleneck away from throughput-oriented acceleration and toward memory bandwidth, cache efficiency, and vectorization. This makes llama.cpp a relevant proxy workload for evaluating modern CPU-based HPC systems in terms of both performance and efficiency [29, 52]. In our evaluation, we use the benchmarking utility provided by llama.cpp, namely llama-bench. The tool enables the configuration of the LLM model, prompt and generated-token lengths, and batch size, and reports the achieved throughput in tokens per second (𝑡𝑜𝑘∕𝑠) for both the prompt-processing and text-generation phases. The experiments are based on GPT-OSS-20B [53], a 20billion-parameter Mixture-of-Experts (MoE) model using Page 8 of 18

Toward Open ISA Supercomputing

FP16 weights. This model was selected to investigate CPUbased inference of an open-weight frontier model while keeping the execution time of the experiments manageable. We consider a prompt length of 2048 tokens and generate an additional 512 tokens during each inference. The batch size is varied from 1 to 512 in powers-of-two increments via the configurable batch and ubatch sizes that are kept equal to avoid pipelining and its side-effects. For each configuration, experiments are repeated five times while scaling the number of OpenMP threads from one to the maximum number of threads available on the evaluated system. The reported throughput corresponds to the arithmetic mean of the five measurements, expressed in tokens per second (𝑡𝑜𝑘∕𝑠).

5. Results In this section, we discuss the results obtained across the three evaluated platforms using the selected set of synthetic benchmarks and applications. The analysis aims to characterize the performance of the RISC-V SG2044 processor, and to assess its position relative to representative x86-64 and Arm-based competing platforms. As a general rule, we present the results from two complementary perspectives. First, we report the raw performance or time-to-solution, depending on the application. Second, we evaluate scalability through the relative speedup, taking the single-core result as the baseline and considering the scaling up to the maximum number of available cores. The reported runs are, otherwise indicated, the best. In the totality of cases this refers to the process pinning labeled as best in Table 3. Finally, we consider the energy dimension. For benchmarks measuring wall-clock execution time on the same problem size across the evaluated architectures, the comparison is performed directly in terms of total energy consumption, expressed in kJ. This metric captures the total energy required by each platform to complete the same workload. For tests characterized by sustained performance, expressed in GFLOP/s or tok/s, including cases with different problem sizes, energy efficiency is instead measured as the ratio between the achieved performance and the energy consumed, expressed in GFLOP/J or tok/J, respectively.

5.1. Synthetic Benchmarks In this section we will present all the synthetic benchmarks results introduced above: (i) STREAM (ii) HPL (iii) HPCG and (iv) HPL-MxP.

5.1.1. STREAM Previous works [1, 30] highlighted the limitations of the memory subsystem of the previous-generation SG2042 processor. In particular, multi-core scaling rapidly reached the available memory-bandwidth ceiling: depending on the system configuration, bandwidth saturated at four cores on single-socket systems and at eight cores on dual-socket systems. This behavior is visible in Figure 2a, where the yellow curve represents the dual-socket SG2042 system of MCv2. Motivated by this limitation, we investigated whether E. Venieri et al.: Preprint submitted to Elsevier

the redesigned memory subsystem of the SG2044 could improve not only peak bandwidth, but also its scaling behavior. Previous measurements on the SG2044 reported more than a twofold increase in maximum attainable memory bandwidth compared with the SG2042 [2]; however, the scaling behavior across cores was not investigated in detail. Although the SG2044 is a UMA processor, its 64 cores are organized into 16 four-core clusters, each sharing an L2 cache. This organization suggests that core placement may influence the ability to exploit the available memory bandwidth. We therefore evaluated three pinning strategies, as detailed in Section 4.1: os_default, sequential, and l2_cache_aware. Equivalent strategies were evaluated on the Intel and NVIDIA systems by using their NUMA domains as the corresponding hardware locality units. The results are shown in Figure 3. Distributing the workload across NUMA domains, or, for the SG2044, across core clusters, substantially improves parallel scaling compared with concentrating cores within a single locality domain. While expected on NUMA systems, the SG2044 shows that a similar effect can arise in a UMA architecture with sharedcache clusters. Its sequential configuration, shown by the red dash-dotted curve, provides little additional bandwidth once a cluster is saturated, while the unconstrained configuration performs better but does not consistently exploit the available bandwidth. The L2-cache-aware configuration achieves the best scaling by distributing active cores across the 16 clusters. This behavior identifies the point at which the SG2044 approaches memory-bandwidth saturation. With L2-cache-aware placement, bandwidth scales nearly ideally up to 16 cores, reaching a 12.6× speedup, after which gains become marginal and reach only 13.5× at 64 cores (Figure 2b). Compared with the SG2042, where saturation occurred at eight cores, the SG2044 shifts the onset to 16 cores while substantially increasing attainable bandwidth. Figure 2a shows a comparison of the memory-bandwidth evolution across the evaluated platforms. The first generation of Monte Cimone, based on a four-core RISC-V system, achieved only 1.1 GB/s in a single node. This increased to 52.4 GB/s in MCv2, based on the SG2042, and to 107.0 GB/s in MCv3, based on the SG2044. Thus, the aggregate bandwidth increased by approximately 50× between the first and second generations and by approximately 100× between the first and third generations. The SG2044 therefore represents a substantial improvement in the memory performance of the RISC-V platform, although a significant gap remains with the x86-64 and Arm reference systems. In terms of single-core bandwidth, the SG2044 reaches 7.8 GB/s, compared with 14.8 GB/s for Intel Sapphire Rapids and 28.0 GB/s for NVIDIA Grace CPU. The difference is even more pronounced when considering aggregate node bandwidth: the Intel system reaches 409.2 GB/s with 112 cores, while the NVIDIA system reaches 662.3 GB/s with 144 cores, compared with 107.0 GB/s for the 64-core SG2044. Therefore, the SG2044 remains behind the reference platforms in both per-core and aggregate bandwidth. However, absolute bandwidth alone does not capture the Page 9 of 18

Toward Open ISA Supercomputing STREAM Triad - Speedup

STREAM Triad - Raw Bandwidth 103

256.0

NVIDIA Grace (dual_die_interleaved) Intel Sapphire Rapids (numa_aware_distributed) RISC-V MCv3-SG2044 (l2_cache_aware) RISC-V MCv2 (numa_aware_distributed) Ideal

102

101 NVIDIA Grace (dual_die_interleaved) Intel Sapphire Rapids (numa_aware_distributed) RISC-V MCv3-SG2044 (l2_cache_aware) RISC-V MCv2 (numa_aware_distributed) RISC-V MCv1 (full_node)

100 1

2

4

8

16

32

64

128

Parallel Speedup

Bandwidth (GB/s)

128.0 64.0 32.0 16.0 8.0 4.0 2.0 1.0 0.5

1

2

4

8

16

32

64

128

Number of Threads

Number of Threads

(a) Sustained GB/s performance.

(b) Relative speedup scaling.

Figure 2: Memory bandwidth across architectures and generations of Monte Cimone. (a) shows GB/s with scaling number of OpenMP threads (here equal to the number of cores) and (b) relative speedup. STREAM Triad - Speedup Across Pinning Strategies

STREAM Triad - Raw Bandwidth Across Pinning Strategies NVIDIA Grace (dual_socket_interleaved) NVIDIA Grace (sequential) Intel Sapphire Rapids (numa_aware_distributed) Intel Sapphire Rapids (numa_aware_local) Intel Sapphire Rapids (sequential) RISC-V SG2044 (l2_cache_aware) RISC-V SG2044 (sequential) RISC-V SG2044 (os_default)

128.0 64.0

Parallel Speedup

Bandwidth (GB/s)

103

NVIDIA Grace (dual_socket_interleaved) NVIDIA Grace (sequential) Intel Sapphire Rapids (numa_aware_distributed) Intel Sapphire Rapids (numa_aware_local) Intel Sapphire Rapids (sequential) RISC-V SG2044 (l2_cache_aware) RISC-V SG2044 (sequential) RISC-V SG2044 (os_default)

102

32.0 16.0 8.0 4.0 2.0

101

1.0 1

2

4

8

16

32

64

128

Number of Threads

(a) Sustained GB/s performance.

1

2

4

8

16

32

64

128

Number of Threads

(b) Relative speedup scaling.

Figure 3: Memory bandwidth across architectures and different pinning strategies. (a) shows GB/s with scaling number of OpenMP threads (here equal to the number of cores) and (b) relative speedup.

evolution of the memory subsystem, since the ability to scale toward the available bandwidth is equally important. This is illustrated in Figure 2b. At 16 cores, Intel Sapphire Rapids, NVIDIA Grace CPU, and SG2044 achieve speedups of 14.1×, 13.5×, and 12.6×, respectively, relative to single-core execution, compared with the ideal 16×. At their respective maximum core counts, Intel reaches 27.6× at 112 cores, NVIDIA reaches 23.1× at 144 cores, and SG2044 reaches 13.5× at 64 cores. The comparison shows that, although the SG2044 still provides lower absolute memory bandwidth, its redesigned memory subsystem has shifted the saturation point to a significantly higher core count. Consequently, the SG2044 exhibits a scaling behavior that is much closer to that of the Intel and NVIDIA platforms than that of the previous SG2042 generation, demonstrating a substantial improvement in the ability of the RISC-V platform to exploit parallel memory bandwidth.

5.1.2. HPL Following the evolution observed from Monte Cimone v1 to v2, the SG2044-based MCv3 further increases available per core computational power. The SG2044 reaches 8.02 GFLOP/s in single-core HPL, compared to 3.60 GFLOP/s E. Venieri et al.: Preprint submitted to Elsevier

of the SG2042 and 1.86 GFLOP/s of the processor used in MCv1. At the node level, the improvement is substantial: the SG2044 reaches 294 GFLOP/s with 64 cores, compared with 236 GFLOP/s for the SG2042-based node with 128 cores. Thus, the third-generation platform demonstrates a substantial generational improvement with higher peak HPL performance with half the number of cores of MCv2. Figure 4a places these results in the context of the complete testbed. Despite the significant improvement over previous RISC-V generations, the SG2044 remains behind the x86-64 and Arm reference platforms in absolute performance. The difference is already evident at singlecore level: NVIDIA Grace and Intel Sapphire Rapids reach 38.5 GFLOP/s and 76.9 GFLOP/s, respectively, compared with 8.02 GFLOP/s for the SG2044. When normalized to frequency, the relative performance approximately follows the aggregate vector width per core: 128-bit for SG2044, four 128-bit units for Grace, and two 512-bit units for Sapphire Rapids. This indicates the importance of vector resources, although performance depends on instruction throughput, memory behavior, and frequency. The scaling results in Figure 4b provide a different perspective. The SG2044 follows near-linear scaling up to Page 10 of 18

HPL Throughput 104

NVIDIA Grace Intel Sapphire Rapids RISC-V MCv3 - SG2044 RISC-V MCv2 RISC-V MCv1

GFLOP/s

103

102

101

1

2

4

8

16

32

64

128

Cores

(a) Sustained GFLOPS/s performance.

Speedup vs 1 core (4 cores for MCv1)

Toward Open ISA Supercomputing HPL Speedup ideal NVIDIA Grace Intel Sapphire Rapids RISC-V MCv3 - SG2044 RISC-V MCv2 RISC-V MCv1

102

101

100 1

2

4

8

16

32

64

128

Cores

(b) Relative speedup scaling.

Figure 4: HPL throughput in GFLOPS/s (FP64) across architectures and generations of Monte Cimone. (a) shows raw performance with scaling number of MPI processes and (b) relative speedup.

16 cores, after which the speedup increasingly deviates from the ideal curve. At 64 cores, the SG2044 reaches a speedup of 36×, compared with 40× for the dual-socket SG2042. Although the HPL scaling behavior therefore remains less efficient than that of the previous-generation system at this point, the SG2044 achieves substantially higher absolute performance because of its much higher single-core capability. At 64 cores, NVIDIA Grace and Intel Sapphire Rapids reach speedups of 51.9× and 54.8×, respectively. Their scaling also progressively departs from ideality at higher core counts, reaching 73.2× at 144 cores for Grace and 67.8× at 112 cores for Sapphire Rapids. The SG2042 reaches 65.5× at 128 cores. The scaling behavior highlights a trade-off between per-core compute capability and parallel efficiency. At low core counts, the wider vector resources and higher frequencies of NVIDIA and Intel yield higher single-core and aggregate HPL performance. At higher counts, scaling becomes increasingly sublinear, partly due to frequency reduction under high utilization and power constraints, particularly on Sapphire Rapids. For the SG2044, scaling degradation from approximately 16 cores is consistent with the STREAM results. Overall, the SG2044 represents a substantial generational improvement in RISC-V compute performance. Its peak HPL performance reaches 294 GFLOP/s at 64 cores, compared with 1,998 GFLOP/s for NVIDIA Grace at the corresponding 64-core point and 4,209 GFLOP/s for Sapphire Rapids. At their respective maximum core counts, Grace reaches 2,818 GFLOP/s at 144 cores and Sapphire Rapids 5,210 GFLOP/s at 112 cores. The RISC-V platform therefore remains significantly behind the competing architectures in absolute compute throughput, but the progression from MCv1 through MCv2 to MCv3 demonstrates a clear increase in both per-core performance and single-processor computational capability.

5.1.3. HPCG Figure 5 shows HPCG throughput (measured in GFLOP/s) across the three evaluated architectures as a function of E. Venieri et al.: Preprint submitted to Elsevier

the core count, for a fixed 40.5 GB problem size. At the single-core baseline, SG2044 reaches 0.137 GFLOP/s, making it 18.9× slower than Grace at 2.58 GFLOP/s, and 12.1× slower than Sapphire Rapids at 1.66 GFLOP/s. Grace is the first to deviate from ideal scaling, delivering 36.50 GFLOP/s (14.1×) at 16 cores, while Sapphire Rapids is close to ideal at 26.19 GFLOP/s (15.8× speedup), and SG2044 tracks the ideal scaling line at 2.18 GFLOP/s (16.0× speedup). By 32 cores both Arm and x86 platforms experience a noticeable decline in speedup scaling: Grace reaches 57.79 GFLOP/s (22.4× speedup) and Sapphire Rapids reaches 42.72 GFLOP/s (25.8×, 80.6% efficiency). In contrast, SG2044 maintains robust scaling with 4.19 GFLOP/s (30.7× speedup). At 64 cores, while the absolute performance hierarchy remains unchanged (76.96 GFLOP/s on Grace, 53.54 GFLOP/s on Sapphire Rapids, and 7.02 GFLOP/s on SG2044), the scaling behaviour completely reverses. Grace and Sapphire Rapids retain only a fraction of their ideal scaling factor, achieving 29.8× and 32.3× speedup, respectively. Conversely, SG2044 sustains a 51.5× speedup, after peaking at 7.22 GFLOP/s (52.9×, 94.5% efficiency) on 56 cores. The performance gap therefore narrows from 18.9× and 12.1× at one core to 11.0× and 7.6× at 64 cores. At the largest core count of each machine the two server platforms are saturated. Grace plateaus from 72 cores onward (79.34 GFLOP/s), peaking at 79.87 GFLOP/s on 112 cores and settling at 78.87 GFLOP/s on all 144 cores (30.5×, 21.2% efficiency). Sapphire Rapids reaches 54.79 GFLOP/s on 112 cores (33.1× speedup), only 2.3% above its own 64-core result. SG2044 ends at its full 64 cores with 7.02 GFLOP/s (51.4× speedup), which is 11.2× below Grace at 144 cores and 7.8× below Sapphire Rapids at 112 cores in absolute terms.

5.1.4. HPL-MxP From Figure 6 we can see the results of HPL mixed precision throughput (6a) and relative speedup (6b) across the three evaluated architectures as a function of the core

Page 11 of 18

Toward Open ISA Supercomputing HPCG Throughput

HPCG Speedup

NVIDIA Grace

ideal

102

Intel Sapphire Rapids RISC-V SG2044

Speedup vs 1 core

GFLOP/s

10

2

101

100

NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

101

100

10−1

1

2

4

8

16

32

64

128

1

2

4

8

16

Cores

32

64

128

Cores

(a) Strong-scaling sustained GFLOP/s performance.

(b) Relative speedup scaling.

Figure 5: Strong-scaling performance results for the HPCG benchmark on the evaluated platforms as a function of the number of physical cores. (a) shows sustained performance in GFLOP/s, and (b) shows relative speedup. HPL-MxP Throughput

HPL-MxP Speedup

NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

ideal NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

102

Speedup vs 1 core

GFLOP/s

104

103

102

101

100 1

2

4

8

16

32

64

128

1

2

4

Cores

(a) Sustained GFLOPS/s performance.

8

16

32

64

128

Cores

(b) Relative speedup scaling.

Figure 6: HPL MxP throughput in GFLOPS/s (mixed precision) across different architectures. (a) shows raw performance (GFLOP/s) on x-axes over scaling number cores (y-axes) and (b) relative speedup on x-axes over scaling number cores (y-axes).

count, for a fixed memory utilization (>70%). At the singlecore baseline, SG2044 delivers 14.54 GFLOP/s, corresponding to a 12.83× performance deficit relative to Sapphire Rapids, which reaches 186.54 GFLOP/s, and a 5.55× deficit compared with Grace, at 80.68 GFLOP/s. SG2044 moves slightly away at the core count to 4 from the ideal speedup as depicted in 6b and continues to follow near-ideal scaling, reaching 536.55 GFLOP/s (36.90× speedup) at 64 cores. Sapphire Rapids speedup increases up to core count 56 before departing, reaching 6124.67 GFLOP/s (32.83×). Grace remains close to the ideal trend until 112 cores, reaching 5953.04 GFLOP/s (73.79× speedup). At the maximum core count available on each system, the two server platforms reach saturation. Sapphire Rapids levels off from 72 cores onward, attaining a peak of 6747.62 GFLOP/s before settling at 6656.47 GFLOP/s across all 112 cores (35.69×). Grace reaches 6582.40 GFLOP/s at 144 cores (81.59× speedup), just 10.57% above its 112-core result. SG2044 reaches its maximum configuration of 64 cores with 536.55 GFLOP/s (36.90× speedup), remaining 12.27× and 12.41× behind Grace and Sapphire Rapids, respectively, in absolute performance. Overall best speedup is reached by the Grace E. Venieri et al.: Preprint submitted to Elsevier

platform, followed by RISC-V, which overtook Sapphire Rapids at 64 cores.

5.2. Applications In this section we will present all the application results introduced above: (i) iPIC3D, (ii) PLUTO, (iii) OpenFOAM and (iv) llama-bench.

5.2.1. iPIC3D Figure 7a shows iPIC3D’s time-to-solution as a function of active core count on the three architectures. At the singlecore baseline, SG2044 requires 2,895.2 s to complete the simulation, rendering it 14.7× slower than Grace (197.6 s) and 12.6× slower than Sapphire Rapids (229.6 s). As execution scales to 8 cores, Grace and SG2044 demonstrate near-ideal scaling, achieving speedups of 7.6× and 7.3× respectively, while Sapphire Rapids begins to trail with a 6.5× speedup. This scaling hierarchy persists through 16 cores, where Grace reaches a 14.8× speedup, SG2044 reaches 14.4×, and Sapphire Rapids yields 12.7×, and diverges further at 32 cores, yielding speedups of 28.2×, 27.5×, and 24.2×, respectively. At 64 cores, which represents the Page 12 of 18

Toward Open ISA Supercomputing iPIC3D Absolute time-to-solution scaling

iPIC3D Speedup

103

102

101

ideal

102

Intel Sapphire Rapids RISC-V SG2044

Speedup vs 1 core

Time to Solution (s)

NVIDIA Grace

NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

101

100 1

2

4

8

16

32

64

128

1

2

4

8

Cores

16

32

64

128

Cores

(a) Absolute time-to-solution scaling.

(b) Relative speedup scaling.

Figure 7: Strong-scaling results for iPIC3D on the evaluated platforms as a function of the number of physical cores: (a) absolute time-to-solution, (b) relative speedup. PLUTO Absolute time-to-solution scaling NVIDIA Grace Intel Sapphire Rapids

104

ideal NVIDIA Grace

102

RISC-V SG2044

Speedup vs 1 core

Time to Solution (s)

PLUTO Speedup

103

102

101

Intel Sapphire Rapids RISC-V SG2044

101

100 1

2

4

8

16

32

64

128

Cores

(a) Absolute time-to-solution scaling.

1

2

4

8

16

32

64

128

Cores

(b) Relative speedup scaling.

Figure 8: Strong-scaling results for PLUTO on the evaluated platforms as a function of the number of physical cores: (a) absolute time-to-solution, (b) relative speedup.

maximum core count measured on both SG2044 and Sapphire Rapids, the absolute time-to-solution drops to 3.998 s on Grace, 5.647 s on Sapphire Rapids, and 59.967 s on SG2044. At this stage, SG2044 achieves a 48.3× speedup over its single-core baseline, closely tracking the 49.4× speedup observed on Grace, whereas Sapphire Rapids lags significantly with a 40.7× speedup. Despite this competitive relative scaling, SG2044 remains 15.0× slower than Grace and 10.6× slower than Sapphire Rapids in absolute terms. Ultimately, Grace alone is able to effectively scale further to 128 cores, achieving a final time-to-solution of 2.578 s (a 76.6× overall speedup).

5.2.2. PLUTO Figure 8a shows PLUTO’s time-to-solution as a function of core count on the three architectures. On a single core SG2044 takes 15,223 s, 15.5× slower than Grace (980.8 s) and 12.2× slower than Sapphire Rapids (1,244 s). Up to 16 cores all three scale close to ideal, with Grace and Sapphire Rapids the first to fall behind, both at roughly 92% efficiency (92.0% and 92.3%, respectively), while SG2044 is still at 100.3%. By 32 cores the gap widens: SG2044 still scales E. Venieri et al.: Preprint submitted to Elsevier

well at 30.1× (94.1% efficiency), while Grace reaches 26.2× (82.0%) and Sapphire Rapids only 24.7× (77.1%). At 64 cores, SG2044’s full node, the absolute ranking is unchanged (26.8 s on Grace, 35.4 s on Sapphire Rapids, 296 s on SG2044), but efficiency is reversed: SG2044 retains 80.3% (51.4×), against 57.2% (36.6×) on Grace and just 54.9% (35.1×) on Sapphire Rapids. The absolute gap therefore narrows from 15.5× and 12.2× at one core to 11.1× and 8.4× at 64 cores. At their largest core counts, both x86 and Arm platforms are well past this point: Grace peaks at 112 cores (22.6 s, 43.4×, 38.7% efficiency) and settles slightly at 144 cores (23.6 s, 41.6×, 28.9%), while Sapphire Rapids reaches 31.8 s at 112 cores (39.1×, 34.9%). SG2044 ends at its full 64 cores with 296 s, 9.3× slower than Sapphire Rapids at 112 cores and 12.6× slower than Grace at 144 cores (13.1× against Grace’s 112-core peak) in absolute terms, but at more than twice their parallel efficiency.

5.2.3. OpenFOAM Figure 9a shows OpenFOAM strong scaling on the 6Mcell Windsor body mesh. On a single core SG2044 takes 11,034.8 s. It is 10.5× slower than Grace, at 1,053.2 s, and Page 13 of 18

Toward Open ISA Supercomputing OpenFOAM Absolute time-to-solution scaling NVIDIA Grace

103

2

101

ideal

102

Intel Sapphire Rapids RISC-V SG2044

Speedup vs 1 core

Time to Solution (s)

104

10

OpenFOAM Speedup NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

101

100 1

2

4

8

16

32

64

128

Cores

(a) Absolute time-to-solution scaling.

1

2

4

8

16

32

64

128

Cores

(b) Relative speedup scaling.

Figure 9: Strong-scaling results for OpenFOAM on the evaluated platforms as a function of the number of physical cores: (a) absolute time-to-solution, (b) relative speedup.

5.63× slower than Sapphire Rapids, at 1,961.5 s. Up to 8 cores Grace scales close to linearly, at 7.56× speedup, while Sapphire Rapids and SG2044 scale superlinearly, reaching 9.74× and 9.27× respectively (121.8% and 115.9% efficiency). We attribute this superlinear behaviour to a cache effect: as the core count grows, the per-core subdomain shrinks and increasingly fits into the cache hierarchy, raising the effective per-core bandwidth above the single-core baseline. From 16 cores Grace falls below the ideal line (75.97 s and 86.6% efficiency at 16 cores, 50.47 s and 65.2% at 32), while Sapphire Rapids and SG2044 stay close to or above it (107.23 s and 114.3% for Sapphire Rapids, 582.46 s and 118.4% for SG2044 at 16 cores; 66.96 s and 91.5%, 360.23 s and 95.7% at 32). At 64 cores the ranking in absolute performance does not change: 37.64 s on Grace, 50.38 s on Sapphire Rapids, and 284.84 s on SG2044. In parallel efficiency, however, Grace ranks last. Grace retains only 27.98× of the ideal factor of 64, that is 43.7% efficiency; Sapphire Rapids and SG2044 are essentially tied, at 38.93× (60.8%) and 38.74× (60.5%) respectively. SG2044’s fastest run is in fact at 56 cores (274.95 s, 40.13×), after which occupying the full node yields a slight slowdown. The gap to Grace therefore narrows from 10.5× at one core to 7.57× at 64 cores, while the gap to Sapphire Rapids stays essentially unchanged, from 5.63× to 5.65×. At the largest core count of each machine the x86 and Arm platforms are saturated. Grace flattens beyond 128 cores, ending at 33.51 s on all 144 cores (31.43×, 21.8% efficiency). Sapphire Rapids reaches 44.61 s on 112 cores (43.97×, 39.3% efficiency), 11.5% below its own 64-core result. SG2044, whose full node is the 64-core result above, is thus 8.50× slower than Grace at 144 cores and 6.39× slower than Sapphire Rapids at 112 cores in absolute terms, but with 2.77× and 1.54× their parallel efficiency, respectively.

5.2.4. llama.cpp–llama-bench Finally, we report the LLM inference results. The evaluated configurations considered both different OpenMP thread-pinning strategies and batch sizes; here, we report E. Venieri et al.: Preprint submitted to Elsevier

the configurations that generally provided the best performance and scaling for each platform. Figure 10 reports the results obtained with NUMA- and L2-cache-aware thread pinning and a batch size of 512. In general, the difference in computational capability between the SG2044 and the two comparison platforms is more pronounced during Prompt Processing (PP), whereas the performance gap is reduced during Text Generation (TG) and, in some cases, the SG2044 surpasses the Intel platform. At one core, as shown in Figure 10a, the SG2044 achieves 0.79 tok/s in TG and 1.19 tok/s in PP, compared with 2.27 tok/s and 11.10 tok/s for Intel Sapphire Rapids, and 3.23 tok/s and 5.78 tok/s for NVIDIA Grace, respectively. The substantially higher vector-computing capability of Sapphire Rapids translates into the highest PP throughput, whereas Grace, with higher memory bandwidth, achieves the highest TG throughput. This difference is consistent with the distinct characteristics of the two inference phases: PP is primarily compute-bound, while TG is more constrained by memory bandwidth. For PP, the SG2044 scales close to ideally up to 64 cores, reaching 64.6 tok/s and a 54.4× speedup over its single-core performance. NVIDIA Grace achieves both higher throughput, at 340 tok/s, and slightly higher relative scaling, with a 58.8× speedup. Intel Sapphire Rapids reaches the highest absolute throughput at 64 cores, with 427 tok/s, but exhibits lower relative scaling, reaching a 38.5× speedup. Beyond 64 cores, the difference in scaling efficiency becomes more pronounced: Sapphire Rapids reaches 489 tok/s at 112 cores, corresponding to a 44.1× speedup over one core, while NVIDIA Grace continues to scale more effectively, reaching 587 tok/s at 144 cores and a 101.5× speedup. Considering TG, all platforms exhibit a stronger degradation of per-core performance as the core count increases. NVIDIA Grace achieves the highest absolute throughput, whereas the SG2044 provides the highest relative scaling among the evaluated platforms. At 64 cores, the SG2044 reaches 17.4 tok/s, corresponding to a 22.1× speedup over one core. NVIDIA Grace reaches 50.9 tok/s, with a 15.7× speedup, while Intel Sapphire Rapids reaches 14.0 tok/s Page 14 of 18

Toward Open ISA Supercomputing

llama-bench (gpt-oss-20b-F16, b_size=512) PP and TG Speedup

llama-bench (gpt-oss-20b-F16, b_size=512) PP and TG Performance

103

NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

Speedup vs 1 core

tokens/s

102

101 PP TG

100 1

2

4

ideal NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

102

8

16

Cores

32

64

128

(a) Prefill (PP) and decode (TG) sustained tok/s scaling.

101

PP TG

100 1

2

4

8

16

Cores

32

64

128

(b) Prefill (PP) and decode (TG) relative speedup scaling.

Figure 10: llama-bench scaling results obtained with gpt-oss-20b-F16 model and batch size equal to 512

and a 6.1× speedup. These results illustrate the different scaling characteristics of the two inference phases. In the compute-bound PP phase, the SG2044 has substantially lower single-core performance than the two comparison platforms, reflecting its lower computational throughput, but maintains good scaling with increasing core count. In the more memory-bound TG phase, the SG2044 exhibits a more favorable balance between per-core compute capability and available memory bandwidth, resulting in higher scaling efficiency and, at 64 cores, higher absolute throughput than the Intel Sapphire Rapids system.

5.3. Energy efficiency In this section we continue the discussion of the results, evaluating the energy efficiency for each test. In general the plots, at the different tested core counts, report the average power (bars) and the respective energy efficiency (lines) accordingly to the performance metric of the benchmarks or applications, as discussed in the introduction of this section. As a general trend, in every test each machine shows similar average power and scaling behavior, suggesting that most of the power consumption is independent from the type of workload. In this context, the peak average power measured is in the neighborhood of 1000 W per the Intel Sapphire Rapids, 500 W for the NVIDIA Grace and 95 W for the Sophgo SG2044. Moving to energy efficiency, the SG2044 achieves better values than the Intel Sapphire Rapids platform for several workloads, including HPL-MxP (Figure 11f), OpenFOAM (Figure 11e), and llama-bench TG (Figure 11h). In HPL (Figure 11a) and iPIC3D (Figure 11c), the two platforms exhibit similar efficiency, while HPCG (Figure 11b), PLUTO (Figure 11d), and llama-bench PP (Figure 11g) show a different trend, with comparable efficiency at lower core counts and a progressively higher efficiency for the SG2044 as the core count increases. These trends are correlated with the observed performance scaling. When the SG2044 sustains a near-ideal relative speedup, its energy efficiency increases with the number of active cores, progressively reducing the gap with Sapphire Rapids. Conversely, in workloads where Sapphire Rapids exhibits less E. Venieri et al.: Preprint submitted to Elsevier

favorable scaling, its increasing power consumption is not compensated by a proportional performance increase, resulting in lower energy efficiency at higher core counts. Compared with NVIDIA Grace, the SG2044 generally achieves lower energy efficiency, with two notable cases. In HPL, Sapphire Rapids achieves 4.21 GFLOP/J, compared with 3.98 GFLOP/J for NVIDIA Grace and 3.16 GFLOP/J for the SG2044 (Figure 11a). In llama-bench, instead, the SG2044 achieves the highest efficiency at 64 cores for both inference phases. For PP, it reaches 1.20 tok/J (Figure 11g), while for TG it reaches 0.209 tok/J (Figure 11h), against 1.14 and 0.159 tok/s of NVIDIA Grace, respectively. These results further illustrate how the relationship between performance scaling and power consumption can substantially affect the relative energy efficiency of the three architectures, particularly as the number of active cores increases. Considering the evolution of the RISC-V platforms across the Monte Cimone generations, the Sophgo SG2044 increases power consumption compared with the first generation SiFive U740, while also providing substantially higher energy efficiency. As shown in Figure 11a, a single MCv1 node, equipped with four SiFive U740 cores, achieves 0.315 GFLOP/J, compared with 0.533 GFLOP/J for the SG2044 in MCv3 at the corresponding data point. The latter is also close to the 0.537 GFLOP/J achieved by the Intel Sapphire Rapids platform. When comparing the aggregated node capabilities of the first and third Monte Cimone generations, energy efficiency increases from 0.315 to 3.16 GFLOP/J, corresponding to a 10× improvement. At the same time, FP64 performance increases from 1.86 to 294 GFLOP/s (Figure 4a), corresponding to a 158× improvement.

5.3.1. Frequency capping To ensure a fair comparison with the Intel Sapphire Rapids processor, given their substantially different base and maximum frequency we also conducted an evaluation with both a Memory Bound and a Compute Bound test while capping the maximum CPU frequency. Figures 11g and 11h include two additional lines corresponding to these Page 15 of 18

Toward Open ISA Supercomputing HPCG Average Power and Energy Efficiency

101

1200 1000 800

100

600 400 200 2

4

8

16

32

64

112

RISC-V SG2044

1200 1000

10−1

800 600 10−2

400 200 0

144

1

2

4

8

16

103

RISC-V SG2044

102

1000 750 101

500

NVIDIA Grace Intel Sapphire Rapids

1600

Node Power (W), bars

NVIDIA Grace Intel Sapphire Rapids

Energy (kJ), lines

RISC-V SG2044

1400 103

1200 1000 800

102

600 400 200

0

1

2

4

8

16

32

0

64

101 1

2

4

8

Cores

16

32

64

112

144

Cores

(c) iPIC3D

(d) PLUTO

OpenFOAM Average Power and Total Energy

HPL-MxP Average Power and Total Energy

NVIDIA Grace Intel Sapphire Rapids

RISC-V SG2044

NVIDIA Grace Intel Sapphire Rapids

2500

1200

103

1000 800 600

102

Energy (kJ), lines

1400

400

Node Power (W), bars

1600

Node Power (W), bars

144

RISC-V SG2044

101

2000 1500

100

1000 500

200 1

2

4

8

16

32

64

112

0

144

1

2

4

8

Cores

16

32

64

112

144

Cores

(e) OpenFOAM

(f) HPL MxP

llama-bench PP Average Power and Energy Efficiency

llama-bench TG Average Power and Energy Efficiency

1000

100

800 600

1400

101

10−1

400

Node Power (W), bars

1200

Intel Sapphire Rapids 1.9 GHz Intel Sapphire Rapids 1.0 GHz

Efficiency (tok/J), lines

NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

1400

Efficiency (GFLOP/J), lines

Node Power (W), bars

(b) HPCG PLUTO Average Power and Total Energy

250

Node Power (W), bars

112

(a) HPL

1250

NVIDIA Grace Intel Sapphire Rapids RISC-V SG2044

1200

Intel Sapphire Rapids 1.9 GHz Intel Sapphire Rapids 1.0 GHz

100

1000 10−1

800 600 400

10−2 200

200 0

64

iPIC3D Average Power and Total Energy

1500

0

32

Cores

Cores

1750

100

Intel Sapphire Rapids

Energy (kJ), lines

1

NVIDIA Grace

1400

Efficiency (tok/J), lines

0

Node Power (W), bars

Node Power (W), bars

1600

RISC-V SG2044 MCv1

Efficiency (GFLOP/J), lines

NVIDIA Grace Intel Sapphire Rapids

1400

Efficiency (GFLOP/J), lines

HPL Average Power and Energy Efficiency 1600

10−2 1

2

4

8

16

32

64

112

144

0

1

2

4

8

16

32

64

112

Cores

Cores

(g) llama-bench Prompt-Processing

(h) llama-bench Text-Generation

144

Figure 11: Synthetic benchmarks and application average power (bars, right axis) and energy efficiency (lines, left axis, HPL, HPCG, HPL-MxP, llama-bench) or energy to solution (lines, left axis, iPIC3D, PLUTO, OpenFOAM). E. Venieri et al.: Preprint submitted to Elsevier

Page 16 of 18

Toward Open ISA Supercomputing

experiments. For PP, reducing the maximum frequency decreases energy efficiency, as this predominantly computebound workload experiences a reduction in throughput that is not sufficiently compensated by the lower power consumption. In contrast, for TG, which is primarily memory-bound, reducing the CPU frequency has little impact on throughput, particularly at 1.9 GHz. The reduction in power consumption therefore improves energy efficiency, although it remains below that achieved by the RISC-V and Arm platforms.

6. Conclusions In this work, we provided an extensive evaluation of the Sophgo SG2044 RISC-V processor, comparing it with two HPC-oriented platforms based on the other major processor ISAs: the Intel Xeon Platinum 8480+ based on x86-64 and the NVIDIA Grace CPU Superchip based on Arm. We evaluated the SG2044 both as a standalone platform and as the compute node of Monte Cimone, a RISC-V cluster that has evolved through multiple generations of RISC-V hardware, providing a broader perspective on the development of RISC-V platforms for HPC. In absolute performance, the SG2044 remains 8–15× behind the evaluated Intel and NVIDIA platforms across classical HPC workloads. However, it substantially improves computational capability and memory bandwidth over previous RISC-V generations, while its balance of per-core performance and system resources enables competitive scaling in HPCG, PLUTO, OpenFOAM, and LLM inference. Its energy efficiency is comparable to Intel across several workloads, while it exceeds Grace in the 64-core llama-bench tests and markedly improves over previous Monte Cimone generations. Overall, these results indicate that RISC-V has progressed substantially from the performance levels of earlier HPC-oriented implementations and is increasingly capable of providing competitive system-level characteristics. The SG2044 scaling and energy-efficiency characteristics demonstrate that performance is not determined solely by peak computational capability. Future RISC-V HPC platforms can benefit from increased compute throughput improving vector capabilities, advancing its memory subsystem to achieve higher aggregated bandwidth, better adopted technology node to improve general efficiency and speed, and continued optimization of software stacks and numerical libraries. The evolution observed across the Monte Cimone generations suggests that these developments can progressively reduce the performance gap with established HPC architectures while preserving the flexibility of an open ISA.

References [1] E. Venieri, S. Manoni, G. Ceccolini, G. Madella, F. Ficarelli, D. Gregori, A. Acquaviva, L. Benini, and A. Bartolini. Monte cimone v2: Hpc risc-v cluster evaluation and optimization. In Sarah Neuwirth, Arnab Kumar Paul, Tobias Weinzierl, and Erin Claire Carson, editors, High Performance Computing, pages 576–585, Cham, 2026. Springer Nature Switzerland. [2] N. Brown. Is risc-v ready for high performance computing? an evaluation of the sophon sg2044. In Proceedings of the SC ’25

E. Venieri et al.: Preprint submitted to Elsevier

Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC Workshops ’25, page 1703–1711, New York, NY, USA, 2025. Association for Computing Machinery. [3] M. Perotti, M. Cavalcante, R. Andri, L. Cavigelli, and L. Benini. Ara2: Exploring single- and multi-core vector processing with an efficient rvv 1.0 compliant open-source processor. IEEE Transactions on Computers, 73(7):1822–1836, 2024. [4] F. Minervini, O. Palomar, O. Unsal, E. Reggiani, J. Quiroga, J. Marimon, C. Rojas, R. Figueras, A. Ruiz, A. Gonzalez, J. Mendoza, I. Vargas, C. Hernandez, J. Cabre, L. Khoirunisya, M. Bouhali, J. Pavon, F. Moll, M. Olivieri, M. Kovac, M. Kovac, L. Dragic, M. Valero, and A. Cristal. Vitruvius+: An area-efficient risc-v decoupled vector coprocessor for high performance computing applications. ACM Transactions on Architecture and Code Optimization, 20(2), June 2023. [5] H. Pizzini Cavagna, D. Cesarini, and A. Bartolini. Assessing tenstorrent’s risc-v matmul acceleration capabilities. In Sarah Neuwirth, Arnab Kumar Paul, Tobias Weinzierl, and Erin Claire Carson, editors, High Performance Computing, pages 123–134, Cham, 2026. Springer Nature Switzerland. [6] F. Banchelli, D. Jurado, M. Garcia-Gasulla, and F. Mantovani. Exploring risc-v long vector capabilities: A case study in earth sciences. Future Generation Computer Systems, 174:107932, 2026. [7] J. L. Almerol, N. Shukla, F. Ficarelli, G. S. Karademir, A. Bartolini, E. Venieri, G. Madella, and E. Boella. Is risc-v ready for massively parallel astrophysical codes? arXiv:2606.15490, 2026. [8] P. Diehl, P. Syskakis, G. Daiß, S. R. Brandt, A. Kheirkhahan, S. Y. Singanaboina, D. Marcello, C. Taylor, J. Leidel, and H. Kaiser. Preparing for hpc on risc-v: Examining vectorization and distributed performance of an astrophysics application with hpx and kokkos. In Proceedings of the SC ’24 Workshops of the International Conference on High Performance Computing, Network, Storage, and Analysis, SC-W ’24, page 1656–1665. IEEE Press, 2025. [9] F. Mantovani, M. Garcia-Gasulla, J. Gracia, E. Stafford, F. Banchelli, M. Josep-Fabrego, J. Criado-Ledesma, and M. Nachtmann. Performance and energy consumption of hpc workloads on a cluster based on arm thunderx2 cpu. Future Generation Computer Systems, 112:800–818, 2020. [10] F. Banchelli, F. Mantovani, and F. Spiga. Cross-architecture power efficiency analysis through micro-benchmarking. In Proceedings of the Supercomputing Asia and International Conference on High Performance Computing in Asia Pacific Region Workshops, SCA/HPCAsiaWS ’26, page 122–132, New York, NY, USA, 2026. Association for Computing Machinery. [11] D. Suárez, F. Almeida, and V. Blanco. Comprehensive analysis of energy efficiency and performance of arm and risc-v socs. J. Supercomput., 80(9):12771–12789, February 2024. [12] Nikolay A. Simakov, Robert L. Deleon, Joseph P. White, Matthew D. Jones, Thomas R. Furlani, Eva Siegmann, and Robert J. Harrison. Are we ready for broader adoption of arm in the hpc community: Performance and energy efficiency analysis of benchmarks and applications executed on high-end arm systems. In Proceedings of the HPC Asia 2023 Workshops, HPCAsia ’23 Workshops, page 78–86, New York, NY, USA, 2023. Association for Computing Machinery. [13] A. Jackson, A. Turner, M. Weiland, N. Johnson, O. Perks, and M. Parsons. Evaluating the arm ecosystem for high performance computing. In Proceedings of the Platform for Advanced Scientific Computing Conference, PASC ’19, New York, NY, USA, 2019. Association for Computing Machinery. [14] Nikolay A. Simakov, Matthew D. Jones, Thomas R. Furlani, Eva Siegmann, and Robert J. Harrison. First impressions of the nvidia grace cpu superchip and nvidia grace hopper superchip for scientific workloads. In Proceedings of the International Conference on High Performance Computing in Asia-Pacific Region Workshops, HPCAsia ’24 Workshops, page 36–44, New York, NY, USA, 2024. Association for Computing Machinery.

Page 17 of 18

Toward Open ISA Supercomputing [15] J. Laukemann, G. Hager, and G. Wellein. Microarchitectural comparison and in-core modeling of state-of-the-art cpus: Grace, sapphire rapids, and genoa. In Proceedings of the SC ’24 Workshops of the International Conference on High Performance Computing, Network, Storage, and Analysis, SC-W ’24, page 1405–1412. IEEE Press, 2025. [16] R. Li, A. N. D. Jacob, N. J. Yadwadkar, and L. K. J. John. Spec cpu2026: Characterization, representativeness, and cross-suite comparison. ArXiv, abs/2605.03713, 2026. [17] A. Bartolini, F. Ficarelli, E. Parisi, F. Beneventi, F. Barchi, D. Gregori, F. Magugliani, M. Cicala, C. Gianfreda, D. Cesarini, A. Acquaviva, and L. Benini. Monte cimone: Paving the road for the first generation of risc-v high-performance computers. In 2022 IEEE 35th International System-on-Chip Conference (SOCC), pages 1–6, 2022. [18] C. Gómez, F. Mantovani, E. Focht, and M. Casas. Hpcg on longvector architectures: Evaluation and optimization on nec sx-aurora and risc-v. Future Generation Computer Systems, 143:152–162, 2023. [19] E. Lazzeri, G. Furano, and L. Cassano. An experimental evaluation of risc-v cores: Software support and performance analysis. Journal of Systems Architecture, 178:103871, 2026. [20] J. McCalpin. Memory bandwidth and machine balance in high performance computers. IEEE Technical Committee on Computer Architecture Newsletter, pages 19–25, 12 1995. [21] A. Petitet, R. Whaley, J. Dongarra, and A. Cleary. Hpl – a portable implementation of the high-performance linpack benchmark for distributed-memory computers. 01 2008. [22] J. Dongarra and P. Luszczek. Hpl-mxp benchmark: Mixed-precision algorithms, iterative refinement, and scalable data generation. Int. J. High Perform. Comput. Appl., 40(1):52–62, January 2026. [23] J. Dongarra, M. A. Heroux, and P. Luszczek. High-performance conjugate-gradient benchmark: A new metric for ranking highperformance computing systems. The International Journal of High Performance Computing Applications, 30(1):3–10, 2016. [24] S. Markidis, G. Lapenta, et al. Multi-scale simulations of plasma with ipic3d. Mathematics and Computers in Simulation, 80(7):1509–1519, 2010. [25] A. Mignone, G. Bodo, and et al. Pluto: A numerical code for computational astrophysics. The Astrophysical Journal Supplement Series, 170:228, 2007. [26] H. G. Weller, G. Tabor, H. Jasak, and C. Fureby. A tensorial approach to computational continuum mechanics using object-oriented techniques. Comput. Phys., 12(6):620–631, November 1998. [27] H. Jasak. Openfoam: Open source cfd in research and industry. International Journal of Naval Architecture and Ocean Engineering, 1(2):89–94, 2009. [28] G. Gerganov and contributors. llama.cpp: Llm inference in c/c++. https://github.com, 2023–2026. [29] A. Marques Garcia, G. Malenza, R. Birke, and M. Aldinucci. Inference performance of large language models on a 64-core risc-v cpu with silicon-enabled vectors. Future Generation Computer Systems, 177:108242, 2026. [30] N. Brown and M. Jamieson. Performance characterisation of the 64-core sg2042 risc-v cpu for hpc. In ISC High Performance 2023 International Workshops — High Performance Computing, Lecture Notes in Computer Science. Springer Nature, June 2024. Fourth International Workshop on RISC-V for HPC, Hamburg, Germany, 16 May 2024. [31] G. Mittone, N. Tonci, R. Birke, I. Colonnelli, D. Medić, A. Bartolini, R. Esposito, E. Parisi, F. Beneventi, M. Polato, M. Torquati, L. Benini, and M. Aldinucci. Experimenting with emerging risc-v systems for decentralised machine learning. In Proceedings of the 20th ACM International Conference on Computing Frontiers, CF ’23, page 73–83, New York, NY, USA, 2023. Association for Computing Machinery. [32] S. Nassyr, P. Chawla, D. Seibel, J. Badwaik, K. H. Mood, and A. Herten. Great expectations: Benchmarking the real-world performance of rvv 1.0 in hpc, 2026. [33] D. Seibel, K. H. Mood, J. Badwaik, P. Chawla, S. Nassyr, and A. Herten. Performance evaluation of fast fourier transforms on emerging risc-v hardware with vector extension support, 2026.

E. Venieri et al.: Preprint submitted to Elsevier

[34] TOP500. Top500 highlights – june 2026. https://www.top500.org/ lists/top500/2026/06/highs/, 2026. Processor Technologies statistics, accessed July 2026. [35] Intel Corporation. Intel® 64 and IA-32 Architectures Optimization Reference Manual, 2024. [36] Chips and Cheese. Golden cove: Intel’s largest performance core. https://old.chipsandcheese.com/2021/12/02/popping-the-hoodon-golden-cove, 2022. Accessed: 2026-08-04. [37] Magnus Bruce. The value of arm neoverse compute subsystems (css). Hot Chips 35, 2023. Arm presentation. [38] Xuantie. Xuantie C920. Processor IP product page. [39] RISC-V Compute Server SRA3-40 Product Page. [40] A. Bartolini, F. Beneventi, A. Borghesi, D. Cesarini, A. Libri, L. Benini, and C. Cavazzoni. Paving the way toward energy-aware and automated datacentre. In Workshop Proceedings of the 48th International Conference on Parallel Processing, ICPP Workshops ’19, New York, NY, USA, 2019. Association for Computing Machinery. [41] Michael A. Heroux, Jack Dongarra, and Piotr Luszczek. HPCG technical specification. Technical Report SAND2013-8752, Sandia National Laboratories, Albuquerque, NM and Livermore, CA, 2013. [42] J. Dongarra and P. Luszczek. Hpl-mxp benchmark: Mixed-precision algorithms, iterative refinement, and scalable data generation. The International Journal of High Performance Computing Applications, 40(1):52–62, 2025. [43] K. Madduri, S. Williams, S. Ethier, L. Oliker, J. Shalf, E. Strohmaier, and K. Yelicky. Memory-efficient optimization of gyrokinetic particle-to-grid interpolation for multicore processors. In Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis, pages 1–12, 2009. [44] Jenny Lynn Almerol, Nitin Shukla, Federico Ficarelli, Geray S. Karademir, Andrea Bartolini, Emanuele Venieri, Giacomo Madella, and Elisabetta Boella. Is risc-v ready for massively parallel astrophysical codes? 2026. [45] Burton D. Fried. Mechanism for instability of transverse plasma waves. The Physics of Fluids, 2(3):337–337, 1959. [46] M. Varney. Base drag reduction for squareback road vehicles. PhD thesis, Loughborough University, 2019. [47] 1st Automotive CFD Prediction Workshop (AutoCFD). https:// autocfd.org/case1/. Case 1: Windsor Squareback. [48] P. Sanders and C. Schulz. Think Locally, Act Globally: Highly Balanced Graph Partitioning. In Proceedings of the 12th International Symposium on Experimental Algorithms (SEA’13), volume 7933 of LNCS, pages 164–175. Springer, 2013. [49] S.V Patankar and D.B Spalding. A calculation procedure for heat, mass and momentum transfer in three-dimensional parabolic flows. International Journal of Heat and Mass Transfer, 15(10):1787–1806, 1972. [50] W. Briggs, V. Henson, and S. McCormick. A Multigrid Tutorial, 2nd Edition. 01 2000. [51] Y. Saad. Iterative Methods for Sparse Linear Systems. Society for Industrial and Applied Mathematics, Philadelphia, PA, 2nd edition, 2003. [52] S. Na, G. Jeong, B. H. Ahn, J. Young, T. Krishna, and H. Kim. Understanding performance implications of llm inference on cpus. In 2024 IEEE International Symposium on Workload Characterization (IISWC), pages 169–180, 2024. [53] S. Agarwal, L. Ahmad, J. Ai, S. Altman, A. Applebaum, E. Arbus, R. K. Arora, Y. Bai, B. Baker, H. Bao, et al. gpt-oss-120b & gpt-oss20b model card. arXiv preprint arXiv:2508.10925, 2025.

Page 18 of 18

Related documents

• Toward Open ISA Supercomputing: A Comparative Study of RISC-V, Arm, and x86 Architectures on HPC Workloads#1448148
• Great Expectations: Benchmarking the Real-World Performance of RVV 1.0 in HPC#784857
• Great Expectations: Benchmarking the Real-World Performance of RVV 1.0 in HPC#783267
• HEL: A Heterogeneous Extensible Layer for GPU-Resident Runtime Orchestration#1389776
• HEL: A Heterogeneous Extensible Layer for GPU-Resident Runtime Orchestration#1381210