Great Expectations: Benchmarking the Real-World Performance of RVV 1.0 in HPC

Great Expectations: Benchmarking the Real-World Performance of RVV 1.0 in HPC

arXiv:2608.28097v1 [cs.DC] 28 Aug 2026

Stepan Nassyr1 [0000-0002-0035-244X] , Prateek Chawla1 [0000-0001-8895-2791] , Daniel Seibel1 [0000-0003-3833-2089] , Jayesh Badwaik1 [0000-0002-5252-8179] , Kaveh Haghighi Mood1 [0000-0002-8578-4961] , and Andreas Herten1 [0000-0002-7150-2505] Jülich Supercomputing Centre - Forschungszentrum Jülich GmbH, Jülich, Germany

Abstract. Following the ratification of the RISC-V Vector Extension (RVV) 1.0, new commercially available silicon has been adopting the extension. This paper revisits the question of RISC-V viability for HighPerformance Computing (HPC) by benchmarking the latest RVV 1.0capable hardware (SiFive X280 (Tenstorrent Blackhole), SpacemiT X60 (K1) and X100/A100 (K3), and T-Head C920v2 (Sophon SG2044)). We assess these platforms using standard HPC benchmarks (BLAS, FFTW, HPL, HPCG) and synthetic workloads (STREAM, FMA throughput) and compare them to a state-of-the-art HPC ARM64 chip (NVIDIA Grace). Our findings show that while RVV 1.0 delivers significant performance improvements over scalar execution, hardware-specific implementation challenges remain. We detail these performance characteristics and discuss the remaining hurdles for RISC-V, including RVV, to become a mainstay in the HPC landscape. Keywords: RISC-V · RISC-V RVV · HPC · SIMD/vector instructions · BLAS · FFT · HPL · HPCG · Benchmarking · Performance

1

Introduction

RISC-V is a relatively recent instruction set architecture released under a permissive license that enables royalty-free hardware development. While it has traditionally been associated with low-power and embedded systems, it has matured significantly over the past decade, with increasing efforts targeting highperformance computing (HPC) systems [3, 12]. As part of this evolution, RISC-V Vector Extension (RVV) [11] was ratified in 2021 and incorporated into the RVA23 profile [10], providing a standardized foundation for vectorization on future RISC-V systems. A central design feature of RVV is its vector-length-agnostic (VLA) programming model, which allows applications to be expressed independently of the underlying hardware vector length. This avoids the portability limitations of fixed-width SIMD extensions such as AVX and AVX-512 [8], where software must explicitly target specific

2

S. Nassyr et al.

vector widths. By decoupling software from hardware vector length, RVV enables both portability and scalability across implementations with differing microarchitectural characteristics. RVV further introduces architectural features that are directly relevant for HPC workloads, including flexible vector register configurations, efficient memory access mechanisms, and support for complex data movement patterns through permutation and gather/scatter operations. These features are particularly important for computational kernels dominated by dense linear algebra, stencil computations, and memory-bound workloads. In recent years, the first RISC-V processors targeting HPC workloads with support for the ratified RVV 1.0 specification have started to emerge. Before ratification, researchers evaluated a range of computational workloads on the proposed RVV 0.7. For instance, Vizcaíno et al. analyzed the performance of multiple applications on a long-vector prototype implementation of RVV [16, 15]. In a more recent study, Banchelli et al. evaluated RISC-V long-vector capabilities for Earth science applications [1]. In another study [2] evaluated the Sophon SG2044 using the NAS Parallel Benchmark suite, raising the question of whether RISC-V is ready for HPC. In this work, we consider four such platforms from different vendors. The Tenstorrent Blackhole device features a number of SiFive X280 cores, used for supportive tasks for the array of central Tensix cores. The SpacemiT K1 with its X60 cores is one of the first RISC-V CPUs with RVV support. Its successor, the SpacemiT K3 featuring X100 and A100 cores is not yet commercially available and was accessed via a cloud-based beta testing environment. The Sophon SG2044, based on Xuantie C920v2 cores, is the only dedicated, commercially-available server-class RISC-V processor with full RVV 1.0 support at the time of writing and has also been used in prior performance studies [2]. In this work, we revisit the question of RISC-V viability for High-Performance Computing (HPC) with a focus on numerical libraries enabled for RVV and a broader set of RVV 1.0-capable hardware platforms. We benchmark the considered platforms using a combination of standard HPC benchmarks (BLAS, FFTW, HPL, HPCG) and synthetic workloads (STREAM and floating-point throughput tests) enabling a characterization of both computational capabilities and memory subsystem behavior. Furthermore, we compare these findings to the ARM-based NVIDIA Grace CPU to establish a performance baseline with a well-known CPU and contextualize the efficiency of the emerging RISC-V platforms within the broader HPC landscape. The results provide insights into how RVV 1.0 support translates into performance across different implementations and highlight the impact of architectural design choices on observed performance characteristics. The rest of the paper is structured as follows. Section 2 provides an overview of the evaluated hardware platforms and the benchmarking methodology. Section 3 presents the results of both synthetic and standard HPC benchmarks. Finally, section 4 summarizes the key findings and outlines directions for future work.

Title Suppressed Due to Excessive Length

2

3

Background

In this section, we present the devices under test, and the benchmarks used for assessment. 2.1

Hardware

Table 1. Processor Architecture and Performance Comparison. Since the L2 cache is shared for some processor designs, the number of N sharing cores is indicated in the form of "/N c".

Metric

Unit

Arch. Release Date #Cores VLEN

bit

DLEN

bit

SpacemiT

Sophon

TT

K3

K3

SG2044

Blackhole Grace

X60 X100 04/2024 04/2026

A100 04/2026

C920v2 02/2025

X280 04/2025

Neoverse V2 05/2023

8 256

4x4 512

72 128

256

512

224

3550

K1

8 256

NVIDIA

256

256

Peak Perf GFLOP/s (FP64) Peak Per- GFLOP/s f/core (FP64) Peak Per- GFLOP/s f/core (FP32) L1d KiB Cache L2 Cache KiB L3 Cache MiB Clock GHz Freq.

102.4

140.8

8 64 1024 128 256 (FP64) 256 512 (FP32) 155.2 1331.2

12.8

17.6

14.4

20.8

14

55.3

25.6

35.2

57.6

41.6

28

110.6

32

64

64

64

32

64

512/4c 1.6

8192/8c 2.2

8192/8c 1.8

2048/4c 64/64c 2.6

128/1c 2/4c 1.75

1024/1c 114/72c 3.1 (max. 3.456)

Frontend

2-way iO 4-way OoO 2-way iO

3-dispatch/ 4-commit/ 2-way iO 8-issue OoO

6-wide OoO

Table 1 shows a selection of relevant architectural details of the processors we evaluate in this work. All of the processors support RVV 1.0, however they differ in the underlying Single-Instruction-Multiple-Data (SIMD)/vector configurations. The X60, X100 and C920v2 [14] cores have a SIMD-like setup, with a theoretical throughput of a full Vector Length (VLEN) RVV Fused MultiplyAccumulate (FMA) instruction per-cycle, while the x280 and A100 cores have a different VLEN and Vector Datapath Length (DLEN), resulting in a full VLEN instruction to take 2 and 4 cycles respectively. This makes their design closer to a vector unit than SIMD. The HPC reference system is the NVIDIA’s Grace CPU based on the ARM Neoverse V2 architecture supporting ARM’s latest SIMD extension, SVE2. Grace was chosen since the SIMD extension SVE is, similar to RVV, vector-length-agnostic and NVIDIA’s Grace is currently the best-performing SVE implementation available on the market.

4

2.2

S. Nassyr et al.

Benchmarks

To evaluate the processors, we use a small set of synthetic and application benchmarks. These are chosen to cover both peak compute behaviour and more realistic HPC workloads, as well as to expose potential bottlenecks in the execution and memory subsystems. FMA throughput We devised a synthetic benchmark that generates assembly loops containing a chain of independent RVV vfmacc instructions. This allows us to measure the peak computational throughput of each chip for different datatypes. While the application benchmarks we tested use primarily FP64 and FP32 precision, we investigated FP16 throughput for this benchmark, since all of the processors advertise AI focus and it is important to determine whether performance behaviour differs between lower and higher-precision compute. We added an option to insert vle instructions into the FMA chain at a given ratio. The inserted load instructions use vector registers that aren’t used in the vfmacc chain and always load from the same address. This allows us to specifically investigate whether there is a bottleneck in the frontend, insufficient L1 port width or some kind of port contention between the Vector Floating-Point Unit (VFPU) and Vector Load-Store Unit (VLSU). STREAM The STREAM benchmark is a synthetic benchmark which measures the sustainable memory bandwidth of a compute node. It only uses little to no computation per byte transferred to or from memory. BLAS Basic Linear Algebra Subroutines (BLAS) is a collection of dense linearalgebra routines important for HPC applications. Different implementations of BLAS exist, we focused mainly on the BLIS [13] and OpenBLAS [17] libraries. For BLIS we also created a mechanism that allowed us to override the block sizes KC , MC and NC without recompilation and wrote an automatic blocksize optimization tool, with which we determined a highly performant blocksize configuration for each Core. FFTW FFTW [6] is the most widely used library for discrete Fourier transforms. Compared to level-3 BLAS and HPL workloads, FFTs are inherently memory bound operations as the arithmetic density is much lower. For our benchmarks, the RVV 1.0-ready version of FFTW by R. Dolbeau [4] has been used. HPL The High Performance Linpack (HPL) benchmark [5] is a widely used dense linear algebra benchmark for evaluating the floating-point performance of HPC systems. It solves a dense system of linear equations using LU factorization with partial pivoting and is the basis for the TOP500 ranking.

Title Suppressed Due to Excessive Length

5

HPCG The High Performance Conjugate Gradient (HPCG) benchmark [7] complements HPL by evaluating performance on workloads representative of sparse iterative solvers. It solves a sparse linear system arising from a threedimensional discretization using a preconditioned conjugate gradient method with domain decomposition and geometric multigrid preconditioning. In contrast to compute-bound dense linear algebra, HPCG emphasizes memory access patterns, communication, and irregular computation, thereby stressing key system characteristics such as memory bandwidth and network latency.

3

Evaluation

In this section, we evaluate the performance characteristics of the considered RISC-V processors using a combination of synthetic and application-level benchmarks. The goal is to systematically analyze both the theoretical capabilities and the practical limitations of the architectures, with particular focus on vector execution, memory hierarchy behavior, and their interaction. 3.1

Synthetic Benchmarks

FMA throughput Table 2 shows our results for the FMA throughput benchmark. We have chosen 5 different FMA/load ratios: only FMAs-baseline, 1, 4, 14, and 26. Ratio 1 represents typical compiler auto-vectorization scenarios. Ratio 4 represents a medium effort manual vectorization for a compute-intensive scenario. Our best-performing GEMM kernel tuned for the SpacemiT X60 has a ratio of 14. Ratio 26 is the maximum possible that can be configured in our tool. All processors are able to reach their advertised peak performance for each data type when executing a pure FMA chain. At a 1:1 ratio between FMA and load instructions, significant slowdown is observed for all processors, the SpacemiT A100 being affected the most, indicating a heavy penalty for frequently switching between load and arithmetic instructions. We observe that the Spacemit X100 and the SiFive X280 cores are able to reach close-to-peak performance with 1 vector load for 4 FMAs. The T-Head C920v2 still exhibits reduced performance at a ratio of 4, but shows close-to-peak performance at 14. The SpacemiT X60 and A100 cores show degraded performance for all ratios, confirming the theory that the VFPU and VLSU have port contention on these related cores. Out of those two, the A100 struggles much more at ratios of 1 and 4, but looks stronger for high ratios and higher precision reaching up to 99% for FP64 at a ratio of 14 and 26. This number, while extremely high, is still noticeably behind the X100, C920v2 and X280 cores, indicating that some resource contention remains. NVIDIA Grace shows how mature the Neoverse V2 ARM64 cores are, higher per-cycle performance and reaching it at a ratio of 4. STREAM The effective memory bandwidth for each chip is measured via memcpy and axpy operations on FP64 data. Since the conventional STREAM

6

S. Nassyr et al. Table 2. FMA-chain throughput in FLOP/cycle (measured) SpacemiT

Sophon

TT

NVIDIA

vfmacc/ Data vle Type

K1 X60

K3 X100

K3 A100

SG2044 Blackhole Grace C920v2 x280 Neoverse V2

baseline 1 4 14 26

FP64 FP64 FP64 FP64 FP64

7.999 2.6624 5.8561 7.4184 7.4176

7.999 4.517 8.0 8.0 8.0

7.999 0.5593 2.6987 7.9238 7.9238

7.9965 1.9989 6.6409 7.9968 7.9973

7.9871 3.2171 7.9873 7.9875 7.9873

15.9999 9.9426 15.9999 15.9999 15.9999

baseline 1 4 14 26

FP32 FP32 FP32 FP32 FP32

15.997 15.999 32.985 5.3256 9.143 1.1441 10.8080 15.999 5.482 12.3996 15.999 30.7966 12.3986 15.999 27.938

15.9926 3.9979 13.4759 15.9918 15.9924

15.9742 6.3894 15.9746 15.9743 15.9742

31.9998 19.8889 31.9998 31.9998 31.9998

baseline 1 4 14 26

FP16 FP16 FP16 FP16 FP16

31.9491 31.998 63.9966 10.6514 18.286 1.4329 21.6148 31.998 7.9228 24.7973 31.998 49.4824 24.7967 31.998 59.4777

31.9778 7.9962 27.1128 31.9859 31.9882

31.9493 12.779 31.9479 31.9482 31.948

63.9997 23.9999 63.9997 63.9997 63.9997

kernels cannot be effectively vectorized for RVV by modern compilers, assembly kernels with explicit RVV 1.0 instructions and a sufficiently high unrolling factor are used to ensure consistent results across the different platforms. For memcpy, besides the regular implementation with unit-stride vector loads (vle64) and stores (vse64), an implementation using segment vector loads (vlseg64) and stores (vsseg64) is considered. This is because segment loads and stores are particularly important in applications like FFT with complex floating-point data, where real and imaginary parts can be extracted without additional permutation instructions. The axpy kernel is implemented in three parts. First a read block with unit-stride vector loads (vle64) of x and y data, then a compute block with FMAs (vfmacc.vf) and finally a store section to y with unit-stride vector stores (vse64). For SVE on Grace, the analogous set of memory instructions (ldp/stp for unit-stride and ld2/st2 for segmented) and arithmetic instructions (fmla) is used. In Figures 1, the bandwidth (read + write) is reported in GB/s for a single core on each platform. Note that the x-axis is scaled logarithmically, while the y-axis is linear. The peak bandwidth in L1 attainable via regular memcpy is between 22 GB/s for the SpacemiT X60 and 80 GB/s for the SpacemiT A100, which, except for the SiFive X280, is below the theoretical peak bandwidth. While the SiFive X280 and the SpacemiT X100 are relatively stable in regards to sustained bandwidth, the SpacemiT X60 and A100 as well the Sophon SG2044 experience high fluctuations in L1 and L2 bandwidth depending on the particular message size. Especially for the Sophon SG2044, the bandwidth can drop by 75%

Title Suppressed Due to Excessive Length

7

in certain cases. Grace reaches a much higher bandwidth with more than 150 GB/s consistently in L1 and L2, which is close to the theoretical maximum. Given that some of the RISC-V cores like the SpacemiT A100 have a higher theoretical bandwidth per cycle (512 bit vs. 378 bit of Grace), not all of the superior bandwidth of Grace can be attributed to its higher frequency solely.

SiFive X280: STREAM bandwidth axpy segment unit-stride

104

105

40 30 20 10 0

106

Size / Bytes

axpy segment unit-stride

50

Bandwidth / GB/s

Bandwidth / GB/s

SpacemiT X60: STREAM bandwidth 20.0 17.5 15.0 12.5 10.0 7.5 5.0

104

(a) SpacemiT X60 SpacemiT X100: STREAM bandwidth 40 35 30 25 20 15 105

SpacemiT A100: STREAM bandwidth

80

Bandwidth / GB/s

Bandwidth / GB/s

axpy segment unit-stride

Size / Bytes

60 40 20 0

106

axpy segment unit-stride

104

(c) SpacemiT X100

104

105

Size / Bytes

(e) Sophon SG2044

Size / Bytes

106

106

Grace: STREAM bandwidth

160

Bandwidth / GB/s

Bandwidth / GB/s

axpy segment unit-stride

103

105

(d) SpacemiT A100

Sophon SG2044: STREAM bandwidth 35 30 25 20 15 10 5

106

(b) SiFive X280

45

104

105

Size / Bytes

140 120 100 80

axpy segment unit-stride

60 103

104

105

Size / Bytes

106

(f) Grace

Fig. 1. STREAM memory bandwidth benchmarks.

Except for the SiFive X280, segmented loads and stores are not able to reach the same bandwidth as unit-stride memory instructions. For the SpacemiT X60 and X100 about 50% of the bandwidth can be reached, while the Sophon SG2044

8

S. Nassyr et al.

maintains about 70% of the bandwidth. The SpacemiT A100 experiences a significant slowdown with segment instructions and can only reach a small percentage of bandwidth. The SiFive X280 on the other hand reaches the theoretical peak of 32 Bytes per cycle in L1 and L2 only with segmented instructions. For SVE, segmented instructions are called 2-element instructions with de-interleaving and on Grace about 75% of the peak bandwidth in L1 and L2 can be sustained similar to the Sophon SG2044. For the axpy kernel, the bandwidth is adequate and remarkably stable for all platforms. For the SpacemiT X60 and X100 as well the Sophon SG2044, axpy shows only a minor loss or even a small gain of bandwidth in L1 compared to memcpy. The impact on bandwidth is more pronounced for the SiFive X280 with a 20% loss in L1 and the SpacemiT A100 with almost 50% less bandwidth in L1. In L2, axpy shows similar levels of performance as memcpy. For Grace the axpy kernel performs exceptionally well, showing that it is able to perform two vector loads, one vector store and one FMA per cycle persistently. Hence even in L3, it is able to reach 100 GB/s of bandwidth. 3.2

HPC Benchmarks

BLAS We evaluate BLAS performance on RVV 1.0 CPUs using the BLIS and OpenBLAS libraries and on NVIDIA Grace using NVPL 25.5. For BLIS we evaluate a version previously tuned for the X60 core, as it has proved to perform very well on all processors. For the X280 core specifically, we also tested the upstreamed sifive_x280 configuration that was contributed by SiFive. For OpenBLAS we chose the Zvl256b configuration for the X100 and x60 cores and Zvl128b for the C920v2. The A100 and X280 were evaluated only with BLIS, as OpenBLAS does not provide a 1024b, 512b or a vector-length agnostic configuration. In the BLIS framework, block size parameters dictate how matrices are partitioned to optimally utilize the multi-level memory hierarchy (caches and registers) and maximize data reuse. Concurrently, the loop parallelization parameters specify how the nested matrix-multiplication loops are distributed across available threads. When using BLIS with our x60-tuned microkernel we tuned the BLIS block sizes MC ,NC and KC for each system individually through a rough 3D scan of the parameter space, blocksizes MR and NR are hardcoded in the microkernel, which uses 2 vector registers for MR and 14 elements for NR , i.e. MR depends on RVV VLEN. We also tuned the BLIS loop parallelisation parameters Jc ,Ic ,Jr and Ir . The threading configuration is shown in Table 3. Figure 3 show our results for SGEMM and DGEMM on each RVV 1.0 processor, while Figure 4 shows GEMM results on NVIDIA Grace with NVPL 25.5 as an ARM comparison. Figure 2 shows the percentage of peak performance reached as a relative efficiency. We observe that while the FMA throughput benchmark shows 80-90% of peak performance should be attainable with our BLIS GEMM microkernel, the performance is not reached on every processor due to insufficient bandwidth from the memory hierarchy even after a blocksize optimization is performed. This includes the vendor implementation of BLIS

Title Suppressed Due to Excessive Length

9

Table 3. BLIS loop threading parameters for the DGEMM/SGEMM benchmarks. Platform Total Threads JC IC JR IR X60 X100 A100 X280 SG2044 Grace

8 8 8 4 64 72

2 1 4 1 2 1 4 1 1 1 8 1 1 1 4 1 1 4 16 1 NVPL (Auto)

for the X280, which in fact is outperformed by our X60-tuned implementation at higher problem sizes. In terms of raw numbers, the 64-core Sophon SG2044 leads, reaching up to 559.6 GFLOP/s for FP64 and 1369.8 GFLOP/s for FP32. The best compute efficiency is achieved with the SpacemiT X100 (75.8% peak FP64, 81.6% peak FP32) and A100 (80% peak FP64, 66.18% peak FP32) cores. NVIDIA Grace beats all RISC-V platforms in absolute numbers, showing that there is still room for improvement, but in terms of efficiency for large matrices, the A100 and X100 perform competitively, showing microarchitectural strength and potential for a scaled-up version.

3HUFHQWDJHRI3HDN

D%/,6)3(IILFLHQF\

E%/,6)3(IILFLHQF\

     



       

1

6SDFHPL7; 6SDFHPL7;

6SDFHPL7$



6RSKRQ6*

       

1

6L)LYH;

19,',$*UDFH

Fig. 2. DGEMM and SGEMM efficiency on RVV 1.0 platforms and NVIDIA Grace (ARM64)

FFTW The results for FFTW’s internal libbench2 benchmark in double precision with default planning (FFTW_MEASURE) are shown in Figure 5 on a single core for each platform. On the left side, the approximate performance in GFLOP/s for 1D c2c discrete Fourier transforms is plotted against the transform size N , while on the right side the performance relative to the peak reported in Table 1 is shown. For better readability, the right plot shows rolling averages with a window size of 5. Note that the GFLOP/s numbers are likely inflated, because FFTW uses the upper bound 5N log2 (N ) instead of the actual number of floating-point

10

S. Nassyr et al.





%/,6WXQHGIRU[ 2SHQ%/$6=YOE 3HDNDW*+]

  



*)/23V

*)/23V



  

       

1

(a) Double Precision on X60

%/,6WXQHGIRU[ 2SHQ%/$6=YOE 3HDNDW*+]



*)/23V

*)/23V



 

       

1

*)/23V

*)/23V

  %/,6WXQHGIRU[ 3HDNDW*+]







1



 

       

1

(i) Double Precision on X280

*)/23V

*)/23V



       

1

%/,6WXQHGIRU[ 2SHQ%/$6=YOE 3HDNDW*+]

 





1





(h) Single Precision on SG2044



*)/23V

%/,6WXQHGIRU[ 9HQGRU%/,6[ 3HDNDW*+]



%/,6WXQHGIRU[ 3HDNDW*+]







(g) Double Precision on SG2044 

1

(f) Single Precision on A100

 

       



1

%/,6WXQHGIRU[ 2SHQ%/$6=YOE 3HDNDW*+]









       



%/,6WXQHGIRU[ 2SHQ%/$6=YOE 3HDNDW*+]

(d) Single Precision on X100

(e) Double Precision on A100

*)/23V

1



(c) Double Precision on X100



       









(b) Single Precision on X60





%/,6WXQHGIRU[ 2SHQ%/$6=YOE 3HDNDW*+]



  %/,6WXQHGIRU[ 9HQGRU%/,6[ 3HDNDW*+]

 



       

1

(j) Single Precision on X280

Fig. 3. DGEMM and SGEMM on RVV 1.0 platforms



*)/23V

*)/23V

Title Suppressed Due to Excessive Length

  

193/ 3HDNDW*+]









1

   



(a) Double Precision on NVIDIA Grace

11

193/ 3HDNDW*+]









1



(b) Single Precision on NVIDIA Grace

Fig. 4. DGEMM and SGEMM on NVIDIA Grace

operations. While the Sophon SG2044 leads with about 6 GFLOP/s for sizes N that fit into the L1 cache, the SpacemiT X100 catches up for L2 bound computations, where a performance of 4 GFLOP/s is reached by both. Since the SpacemiT X100 has the largest L2 cache, it yields the highest performance for larger N as the other RISC-V systems need to access the L3 cache or RAM. The other platforms are not able to reach more than 3 GFLOP/s, although the SiFive X280 and SpacemiT A100 have the highest cache bandwidths. In case of the SiFive X280, this is due to the fact that FFTW’s kernels do not implement segment loads and stores despite them being effective for systems like the SiFive X280, see section 3.1. The SpacemiT A100 exhibits a disproportionate low level performance in accordance with the findings in section 3.1, where a ratio of at least 14 vector FMAs per load is required to hide latency sufficiently, which is not possible for FFT kernels. Indeed, a closer look into FFTW’s planning output reveals that it falls back to serial non-vectorized codelets in the case of the A100. Again, Grace is able to outperform all RISC-V platforms by a factor of three to five depending on the transform size and reaches up to 25 GFLOP/s. However, when measuring in terms of peak performance, the lead is less pronounced with Grace reaching roughly 40 % compared to a maximum of 28 % amongst the RISC-V cores.

FFTW: Absolute single core performance for 1D c2c transforms

FFTW: Single-core efficiency for 1D c2c transforms (rol. avg.) Percentage of Peak / %

Performance / GFLOP/s

25 20 15 10

Sophon SG2044 SiFive X280 SpacemiT K1 X60

SpacemiT K3 X100 SpacemiT K3 A100 Grace

5 0

102

103

104

transform size N

105

0.40 0.35 0.30 0.25 0.20 0.15 0.10 0.05

Sophon SG2044 SiFive X280 SpacemiT K1 X60 102

SpacemiT K3 X100 SpacemiT K3 A100 Grace

103

104

transform size N

Fig. 5. Single-core performance of FFTW for 1D DFTs

105

12

S. Nassyr et al.

HPL HPL was evaluated with X60-tuned BLIS kernels for the SpacemiT X60, X100 and A100, the SiFive X280, and the Sophon SG2044 processors. Although an upstreamed sifive_x280 configuration is available for the X280, our choice was driven by the higher performance observed with the x60-tuned kernels. For NVIDIA’s Grace chip, the specific implementation of HPL shipped by NVIDIA in the HPC benchmarks container v26.02 [9] is used. The MPI/BLIS threading configuration for the benchmarks is shown in Table 4. Table 4. Multi-threaded configuration and BLIS loop threading parameters for the HPL benchmark Platform Total Threads MPI Ranks JC IC JR IR X60 X100 A100 X280 SG2044 Grace

8 8 8 4 64 72

2 2 1 1 4 4

1 1 4 1 1 1 4 1 1 1 8 1 1 1 4 1 1 1 16 1 NVPL (Auto)

Figure 6 shows the results of our benchmarks on each processor. The Sophon SG2044 displays the least single-threaded performance at 5.48 GFLOP/s, with 6.48 GFLOP/s for the raw DGEMM calculation, and about 12.2 % of the total time is spent in panel factorization. The SpacemiT X100 cores show the best multi-threaded performance overall, with the 8-threaded HPL achieving 83.64 GFLOP/s in raw DGEMM, while spending roughly 12.15 % of the total time in panel factorization. This is in contrast to the SG2044 chip, which at maximum threading (in this case, 64 threads) achieves 417.43 GFLOP/s at raw DGEMM, but the overall performance is severely impacted due to it spending 54.22 % of the time in panel factorization. The RISC-V chips tested are completely outmatched by the NVIDIA Grace CPU which achieves 46.37 GFLOP/s in single-threaded HPL, and with 24 total threads (across 2 MPI ranks) about 1084 GFLOP/s are reached in testing. HPCG We evaluated the SpacemiT X60, X100, A100 and the SiFive X280 with the reference kernels in the HPCG benchmark. The reference kernels simulate a “good-enough” parallelized load expected from a (portable) application, providing a good starting point for a real-world scientific workload. In order to compare to a commercially available in-production chip, we also present results for the NVIDIA Grace CPU. The HPCG benchmark was run via the available NVIDIA container [9]. Figure 7 shows the results of our benchmarks on each processor. Memory bandwidth limitations affect the X280 processor quite severely, which is seen in memory-intensive kernels like the WAXPBY (w ← αx + βy) and the SpMV (sparse matrix-vector multiplication). The A100 cores show a higher compute perfor-

Pe fo mance / GFLOP/s

Title Suppressed Due to Excessive Length

13

103

102

Device

X60 X280

101 1

2

3

4

5

6

7

8

12

16

# Th eads

20

X100 A100

24

28

32

SG2044 G ace

36

48

64

72

Fig. 6. Performance characteristics in the HPL benchmark.

mance than the X100 cores, which is a complete reversal of the HPL results from Figure 6. This is not the case for WAXPBY, where the higher clock speed of the X100 still allows it to take the top spot. Overall, the SpacemiT A100 cores provide the best performance for reference HPCG kernels. We also see significant inter-generational improvement between the X100 and its predecessor, the X60. The X100 improves its DDOT performance by a factor of 3.43, and the SpMV by a factor of 2.15. The total memory bandwidth is also improved by a factor of 1.56. However, a real-world comparison to an established microarchitecture (ARM, in this case) exposes a significant performance gap. The A100, the top performer for DDOT, achieved 0.34 GFLOP/s per core, which is roughly half the performance of the Grace chip (0.77 GFLOP/s). This gap is much higher in case of memory bandwidth, where the highest performing chip among the RISC-V lineup, the X100, achieves 0.49 GB/s per core compared to the more optimized Grace CPU, which achieved 6.77 GB/s per core in our testing runs. Data from the Sophon SG2044 could not be obtained due to the cluster being down for maintenance.

X60 X280 X100

0.8

7

A100 G ace

Bandwidth / GB/s

0.6 0.4 0.2

X60 X280 X100

6

A100 Grace

5 1.5 1.0 0.5

al To t

Wr it

MG

Sp MV

PB Y WA X

T DD O

(a) Raw FP performance

e

0.0

0.0

Re ad

Performance / GFLOP/s

1.0

(b) Raw Memory bandwidth

Fig. 7. Compute and memory performance (per-core) on reference HPCG kernels.

14

4

S. Nassyr et al.

Conclusion

In this work, we revisited the question of RISC-V’s readiness for HPC by evaluating five RVV 1.0-capable processors, with a specific focus on the performance of RVV-accelerated numerical libraries. Our synthetic compute and memory throughput benchmarks exposed the physical limits of current hardware, revealing micro-architectural bottlenecks such as execution port contention and memory-hierarchy constraints that frequently prevent workloads from fully utilizing the compute pipelines. These architectural limitations become apparent in our BLAS evaluation, where most platforms struggle to overcome the memory wall, yielding compute efficiencies between 30% and 50%. The SpacemiT K3, however, emerges as a major exception and represents a profound generational leap over the preceding K1. By significantly improving its vector front-end and memory bandwidth, the K3 achieves compute efficiencies of up to 80% on both the X100 and A100 cores. This translates directly into macro-benchmark dominance, with the K3 outperforming the competition in sustained HPL and HPCG throughput. Conversely, our FFTW evaluation highlights the distinct advantages of out-of-order execution, favoring the Sophon SG2044 and SpacemiT X100 cores for complex memory access patterns. Furthermore, broader cross-architecture comparisons with established devices like NVIDIA’s ARM-based Grace CPU reveal that a substantial performance gap still remains, which go beyond differences in clock frequency and advantages in manufacturing fabrication. However, the rapid inter-generational improvements observed across the evaluated RISC-V designs strongly indicate that this performance gap is poised to close. Ultimately, we observe a clear and rapidly accelerating path to the viability of RVV hardware in HPC. Resolving the remaining readiness gaps requires a dual approach: aggressively scaling out core counts, a paradigm proven highly capable by the 64-core Sophon SG2044, while simultaneously eliminating internal pipeline and bandwidth bottlenecks, as demonstrated by the SpacemiT K3. As these design philosophies mature and converge, RISC-V with its RVV extension is positioned to become a genuinely competitive force in the HPC landscape. Acknowledgments. Funding for parts of this work has been received from EuroHPC’s project DARE SGA 1 under Grant Agreement No. 101202459. The authors gratefully acknowledge the Monte Cimone project for providing access to the Sophon compute nodes used in this work.

Title Suppressed Due to Excessive Length

15

References [1] Fabio Banchelli et al. “Exploring RISC-V long vector capabilities: A case study in Earth Sciences”. In: Future Generation Computer Systems 174 (2026), p. 107932. issn: 0167-739X. doi: https://doi.org/10.1016/j.future. 2025.107932. url: https://www.sciencedirect.com/science/article/pii/ S0167739X25002274. [2] Nick Brown. “Is RISC-V ready for High Performance Computing? An evaluation of the Sophon SG2044”. In: Proceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis (Nov. 2025), pp. 1703–1711. doi: 10.1145/ 3731599.3767531. url: /doi/pdf/10.1145/3731599.3767531?download= true. [3] dare-project. url: https://dare-riscv.eu/. [4] Romain Dolbeau. FFTW3 with RVV 1.0 support. https://github.com/ rdolbeau/fftw3/tree/riscv-v-clean. GitHub repository; accessed 2026-0331. 2025. [5] Jack J. Dongarra, Piotr Luszczek, and Antoine Petitet. “The LINPACK Benchmark: past, present and future”. In: Concurrency and Computation: Practice and Experience 15.9 (2003), pp. 803–820. doi: https://doi.org/10. 1002/cpe.728. eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/ cpe.728. url: https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.728. [6] Matteo Frigo and Steven G. Johnson. “The Design and Implementation of FFTW3”. In: Proceedings of the IEEE 93.2 (2005). Special issue on “Program Generation, Optimization, and Platform Adaptation”, pp. 216– 231. doi: 10.1109/JPROC.2004.840301. [7] Michael Allen Heroux, Jack Dongarra, and Piotr Luszczek. HPCG benchmark technical specification. Tech. rep. Sandia National Laboratories (SNLNM), Albuquerque, NM (United States), 2013. [8] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer’s Manual. Intel. 2024. url: https://www.intel.com/content/www/us/en/ developer/articles/technical/intel-sdm.html. [9] NVIDIA HPC-Benchmarks. url: nvcr.io/nvidia/hpc-benchmarks:26.02. [10] RISC-V International. RVA23 Profile Release. Tech. rep. Version 1.0. RISCV International, 2024. url: https : / / docs . riscv . org / reference / profiles / rva23/_attachments/rva23-profile.pdf. [11] RISC-V International. The RISC-V Vector Extension, Version 1.0. Tech. rep. v1.0. RISC-V International, 2021. url: https://github.com/riscv/ riscv-v-spec/releases. [12] The EuPilot Project. url: https://eupilot.eu/. [13] Field G. Van Zee and Robert A. van de Geijn. “BLIS: A Framework for Rapidly Instantiating BLAS Functionality”. In: ACM Trans. Math. Softw. 41.3 (June 2015). issn: 0098-3500. doi: 10.1145/2764454. [14] Emanuele Venieri et al. “Monte Cimone v2: HPC RISC-V Cluster Evaluation and Optimization”. In: High Performance Computing. Ed. by Sarah

16

S. Nassyr et al.

Neuwirth et al. Cham: Springer Nature Switzerland, 2026, pp. 576–585. isbn: 978-3-032-07612-0. [15] P. Vizcaino et al. “Acceleration with long vector architectures: Implementation and evaluation of the FFT kernel on NEC SX-Aurora and RISC-V vector extension”. In: Concurrency and computation: practice and experience 35.20, article e7424 (Sept. 2023). issn: 1532-0626. doi: 10.1002/cpe. 7424. url: https://hdl.handle.net/2117/376024. [16] Pablo Vizcaino et al. “Short Reasons for Long Vectors in HPC CPUs: A Study Based on RISC-V”. In: ACM International Conference Proceeding Series (Nov. 2023), pp. 1543–1549. doi: 10.1145/3624062.3624231. url: https://doi.org/10.1145/3624062.3624231. [17] Zhang Xianyi, Wang Qian, and Zhang Yunquan. “Model-driven Level 3 BLAS Performance Optimization on Loongson 3A Processor”. In: 2012 IEEE 18th International Conference on Parallel and Distributed Systems. 2012, pp. 684–691. doi: 10.1109/ICPADS.2012.97.

Related documents

• Beyond Pre-Training: The Full Lifecycle of Foundation Models on HPC Systems#13058
• CVE-2026-56005 — HIGH 7.1#316036
• CVE-2026-56006 — HIGH 7.1#316037
• GCStack+ and GCScaler+: Closing the calibration gap in GPU performance modelling for modern microarchitectures / Tim Julius Lühnen, Devashree Tripathy, Ulf Kulau, Sohan Lal#1132671
• CVE-2026-56043 — HIGH 7.1#318233