Performance Evaluation of Fast Fourier Transforms on Emerging RISC-V Hardware with Vector Extension Support

arXiv:2608.28076v1 [cs.MS] 28 Aug 2026

Performance Evaluation of Fast Fourier Transforms on Emerging RISC-V Hardware with Vector Extension Support Daniel Seibel[0000−0003−3833−2089] , Kaveh Haghighi Mood[0000−0002−8578−4961] Jayesh Badwaik[0000−0002−5252−8179] , Prateek Chawla[0000−0001−8895−2791] , Stepan Nassyr[0000−0002−0035−244X] , and Andreas Herten[0000−0002−7150−2505] Jülich Supercomputing Centre, Jülich, Germany {k.haghighi.mood,d.seibel}@fz-juelich.de

Abstract. This manuscript presents a performance evaluation of Fast Fourier Transform (FFT) implementations on emerging processors supporting the RISC-V Vector Extension (RVV 1.0). By introducing juFFTe, a light-weight high-performance library for discrete Fourier transforms, it is demonstrated how effective vectorization of performance-critical FFT kernels can be achieved on RVV-enabled hardware. Comprehensive benchmarks on three RVV 1.0-ready processors, the SiFive X280, the X100 core of the SpacemiT K3 and the C920v2 core of the Sophon SG2044, reveal substantial performance improvements of juFFTe1 over the widely used FFTW3 library. Although RVV-enabled platforms show promising results at this stage of development, a comparison with AMD’s Zen 5 architecture indicates that RISC-V needs further maturing to reach the performance of established micro-architectures. Keywords: Fast Fourier Transform · RISC-V · HPC.

1

Introduction

The discrete Fourier transform (DFT) is one of the most fundamental mathematical operations in natural sciences and serves as the backbone of many numerical algorithms thanks to its efficient implementation in the fast Fourier transform (FFT) [31, 34]. FFTs play a crucial role in modern high performance scientific computing landscape, including the solution of partial differential equations found in computational mechanics [19], electromagnetics [26], computational chemistry [21], and physics [5,9,15]. Being a fundamental building block of modern HPC software stacks, it is widely recognized as one of the HPC dwarfs [6,10] and the availability of highly-optimized FFT libraries is often considered a key indicator of the maturity of a software ecosystem targeting high performance. Besides scientific and engineering applications, the FFT is at the center of digital signal processing [22] and image processing [23]. 1

https://github.com/FZJ-JSC/juFFTe

2

D. Seibel et al.

Owing to its central role in numerous applications and libraries, optimizing FFT requires careful consideration of both algorithmic design and hardwarespecific enhancements to ensure consistently high performance across platforms. In the FFT framework, large DFTs are split into smaller DFTs, which constitute the computationally intensive part of the FFT algorithm and, hence, must be carefully optimized for the target hardware. On modern CPUs and accelerators, this typically entails efficient vectorization using intrinsics or assembly tailored to the specific architecture. RISC-V is a relatively new instruction set architecture released under a permissive license that allows for royalty-free hardware development. Although RISC-V has been primarily used in low-power devices, there are ongoing efforts to develop a new generation of chips targeted at the high-performance segment [1, 2]. To this end, the RISC-V Vector extension (RVV) [24] has been ratified in 2021 and added to the RVA23 profile [25] to enable widespread support for vectorization on future RISC-V hardware. Notable features of RVV include the concept of vector-length-agnostic code and the support of variable vector lengths, which avoids the difficulties associated with different vector lengths encountered in vector extensions like AVX and AVX512 [16]. With regards to FFT, RVV offers special movement and permutation instructions that have the potential to significantly speed up the complex multiplications and transpositions part of the performance-critical kernels. Despite the prospect of high-performance RISC-V hardware on the horizon, currently available production FFT libraries provide only limited support for the RISC-V ecosystem. At the time of writing, only the open-source library FFTW3 [14] has been ported. This manuscript addresses this gap by introducing juFFTe, a modern Fortran library inspired by FFTE subroutines [30, 32]. juFFTe reimplements several methods described in FFTE, using modern Fortran (Fortran 90 and later), improving maintainability and usability while preserving the performance-oriented design of the original implementation. With regards to RISC-V, juFFTe leverages the RISC-V Vector Extension in version 1.0 (RVV 1.0) [24] to enable the efficient and performant vectorization of DFT kernels. As part to its modular structure, these performance-critical kernels are isolated from the remaining code, making the library as portable as possible while preserving a high level of performance and optimization. Moreover, it features a unified API and supports the popular FFTW interface to serve as a drop-in replacement. In addition to the introduction of juFFTe, the manuscript’s main contribution is the evaluation of the proposed implementation on state-of-the-art RISC-V hardware, namely the SiFive X280, the SpacemiT K3 and the Sophon SG2044, all supporting RVV 1.0. In various experiments, the performance of juFFTe is analyzed in single and multi-core scenarios and compared against those of FFTW, offering new insights about the hardware as well as vectorization with RVV. It is demonstrated that juFFTe can yield average performance improvements of up to a factor of three depending on hardware due to superior vectorization and

Title Suppressed Due to Excessive Length

3

parallelism. To the best knowledge of the authors, this represents the first in depth study of high-performance FFT on RVV 1.0 capable hardware. The paper is structured as follows: After a brief overview of related work on FFT for RVV and a short introduction to the theory of FFT, the optimizations carried out in juFFTe for RVV are reviewed with a special focus on vectorization. This is followed by a series of benchmarks, where the performance of the library is compared against the FFTW library across different RVV-enabled systems and an x86 reference system.

2

Related Work

FFT has been evaluated on multiple RISC-V platforms using both the base ISA and architectural extensions. Jiang et al. [18] proposed an ISA extension consisting of twelve additional instructions to accelerate FFT on the open-source RISC-V NutShell processor [3]. In a separate work, Jiang et al. [17] introduced Zoozve, an extension to RVV, demonstrating significant improvements in FFT performance. With the emergence of RVV, several studies have explored vectorized FFT implementations. Vizcaino et al. [36] investigated different Radix-2 FFT approaches on an RVV-ready prototype and compared performance with the NEC SX-Aurora VE vector architecture. Perotti et al. [20] evaluated FFT benchmarks on Ara2, an open-source processor compliant with RVV 1.0. At the library level, Zhao et al. [38] optimized PerfMPL-FFT for power-of-two transform sizes on the C910MP CPU [4] and compared performance against the widely used FFTW library [14]. Cross-platform comparisons have also been conducted to evaluate the competitiveness of emerging many-core RISC-V processors. Strack et al. [29] compared FFTW’s performance on conventional x86 CPUs and the Sophon SG2042 processor. Similarly, Brown [8] evaluated the FFT component of NASA’s Parallel Benchmark suite [7] and compared the performance of the Sophon SG2044 and SG2042 with x86 and ARM processors. We further advance these efforts by showcasing the juFFTe library with support for RVV 1.0 to bring high-performance FFT support to RISC-V and by evaluating performance across multiple novel RVV-ready hardware implementations with a systematic comparison against FFTW.

3

Fast Fourier Transform ⊤

The DFT of a complex vector x = (x0 , . . . , xN −1 ) ∈ CN is defined by yk =

N −1 X

kj ωN xj ,

k = 0, . . . , N − 1,

j=0 kj where the complex coefficients ωN = exp (−2πı kj/N ) with ı2 = −1 are called twiddle factors. It can be written as a matrix-vector product y = FN x with pq FN [p, q] = (ωN ). If N = rc, then xr×c [i, j] = xrj+i is obtained by reshaping

4

D. Seibel et al.

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15



void stockham2 ( int n , int l , int r , double complex *x , double complex *y , double complex * tw ) { int lp = l / 2 , rp = r * 2; for ( int j = 0; j < lp ; j ++) { // Twiddle factors come in pairs , but the first is always 1 const double complex tw0 = 1. , tw1 = tw [ j ]; for ( int k = 0; k < r ; k ++) { double complex x0 = x [ j * r + k ] , x1 = x [( lp + j ) * r + k ]; // Apply F_2 butterfly double complex z0 = x0 + x1 , z1 = x0 - x1 ; // Multiply twiddle with factors y [ j * rp + k ] = tw0 * z0 ; y [ j * rp + r + k ] = tw1 * z1 ; } } }



Listing 1.1. Radix-2 Stockham kernel

x into a column-major-ordered r × c two-dimensional array. The central idea underpinning all FFT algorithms is the so-called radix splitting [31, 34]. If N = rm and x ∈ CN , then the DFT of length N can be split into two DFTs of length r and m as follows 
 (FN x)m×r = FN [0 : m − 1, 0 : r − 1] ⊙ Fm x⊤ Fr . (1) r×m Here, ⊙ denotes the Hadamard product or point-wise multiplication of two arrays. The recursive application of Equation 1 leads to the mixed-radix splitting algorithms and variations like the four-step and six-step algorithms [31, 34]. There is an inherent degree of freedom in how the kernels access and store the intermediate data and this aspect leads to different FFT frameworks. Besides the widely known Cooley-Tukey algorithm [11], the Stockham algorithms [28] have been particularly popular for vector hardware, because they access memory contiguously and avoid expensive data rearrangement like bit-reversal permutations. This comes at the cost of a larger memory footprint as an additional workspace vector is required. Nonetheless, most numerical libraries feature auto-sorting kernels. Among open-source efforts, FFTE [30] uses the decimation-in-frequency Stockham algorithm to target SIMD-enabled hardware and VkFFT [33] implements the transposed Stockham algorithm for a wide-range of hardware. Exemplary C code for a radix-2 Stockham kernel with pre-computed twiddle factors is given in Listing 1.1. It can be seen from the code that the computation is divided into two stages, the multiplication with the so called butterfly matrix F2 and the point-wise multiplication with the twiddle factors. Since the kernels encapsulate the computational part of the FFT, it is of critical importance to optimize them to improve performance.

4

Library Optimizations

juFFTe can leverage vectorization in two complementary ways. First, it benefits from compiler-assisted auto-vectorization, allowing modern compilers to gener-



Title Suppressed Due to Excessive Length

5

 1 2 3 4 5 6 7



// Extract columns i to i + bx from x and store as rows in z void pack ( int i , int bx , int ny , int ld , const double complex *x , double complex * z ) { // x and z are column - major for ( int k = 0; k < bx ; k ++) for ( int j = 0; j < ny ; j ++) z [ k * ld + j ] = x [ j * nx + i + k ]; }

8 9 10 11 12 13 14 15 16 17

void v_pack ( int i , int bx , int ny , int ld , const double complex *x , double complex * z ) { for ( int j = 0; j < ny ; j += vl ) { size_t vl = _ _ r i s c v _ v s e t v l _ e 6 4 m 1 ( ny - j ) ; for ( int k = 0; k < bx ; k ++) { v float6 4m1x2_ t xv = _ _ r i s c v _ v l s s e g 2 e 6 4 _ v _ f 6 4 m 1 x 2 (& x [ j * nx + i + k ] , 16 * nx , vl ) ; _ _ r i s c v _ v s s e g 2 e 6 4 (& z [ k * ld + j ] , xv , vl ) ; } } }



Listing 1.2. Serial and vectorized packing (block-transposition) kernels.

ate vector instructions directly from high-level Fortran code. Second, it can employ vectorized kernels written in C or even assembly code with explicit use of vector instructions to further enable fine-grained control over vector operations and efficient utilization of hardware capabilities. Together, these approaches allow juFFTe to effectively exploit vector units and achieve improved performance portability across different platforms. Since writing manually vectorized kernels is cumbersome and error-prone, the kernels for RISC-V have been generated with the help of SPIRAL [13], a domain-specific language and framework for the automatic generation for highly optimized and vectorized DFT kernels. In order to support the RISC-V vector extension, SPIRAL has been extended with C-intrinsics for RVV 1.0 based on the work for ARM‘s vector extension SVE [30]. The generated kernels are vector-length agnostic, which means that they are binary compatible with every implementation of RVV 1.0 regardless of chosen vector length. One particularly useful feature of RVV are the so-called segmented load and store instructions, which operate directly on interleaved complex floating-point data while avoiding additional shuffle instructions. In addition to the kernels generated with SPIRAL, explicit use of C-intrinsics for RVV was required in several situations specific to RVV. In contrast to the handling of AVX-512, both GCC/GFortran (ver. 15.2.0) and Flang (ver 20.1.8) are not able to effectively vectorize block-transposition operations with complex floating-point data like in Listing 1.2. One possible explanation is that segmented load and store operations are treated as expensive in the compiler’s vectorization cost models. Instead of issuing strided vector loads and stores, they use regular unit-strided loads and stores on single complex double elements at a time. Since this essentially restricts the vector length to 128 bits, the full potential of RVV is not realized, making the manual use of RVV intrinsics necessary to achieve



6

D. Seibel et al.

effective vectorization. The routine v_pack() in Listing 1.2 shows how the available vector length can be fully utilized with strided segment loads (vlsseg) and unit-stride segment stores (vsseg) in a vector-length-agnostic manner. It should be noted that future compiler releases are likely to solve this issue by adapting internal cost models that disfavor strided segment loads and stores. Nonetheless, juFFTe allows developers to perform these kinds of necessary optimizations thanks to its modular structure, which isolates performance critical kernels.

5

Benchmarks

The main performance indicator of an FFT implementation is the time t it takes to compute the DFT depending on the transform size. Since the space dimension plays a minor role in the context of vectorization, the standard complex-tocomplex DFT transform in 1D with varying size N is selected as the benchmark problem. The corresponding performance in FLOP/s can be approximated by 5N log2 (N )/t, which is in fact an upper bound. In order to obtain consistent measurements, the time necessary to compute a 1D DFT of size N is recorded across multiple runs and averaged afterwards. The performance of juFFTe is evaluated against an optimized version of FFTW3 with RVV 1.0 support based on the work by R. Dolbau [12]. All computations are carried out in double precision, with multi-threading enabled via OpenMP for both libraries. Except where explicitly stated otherwise, FFTW uses the default FFTW_MEASURE planner flag. For the evaluation of juFFTe, three different RVV 1.0 capable CPUs are considered, the SiFive X280 cores available on the Tenstorrent Blackhole devices, the X100 high-performance cores of the SpacemiT K3 processor and the C920v2 cores of the Sophon SG2044 processor. Their features and capabilities are summarized in Table 1, with the peak compute and memory bandwidth measured experimentally. SiFive X280: The first system under consideration consists of the RISC-V margin nodes of the Tenstorrent Blackhole, which houses four tiles of four SiFive X280 cores each, for a total of 16 cores. The SiFive X280 core is a 8-stage dual-issue in-order 64-bit RISC-V CPU with a vector length (VLEN) of 512 bit and 256 bit datapath (DLEN). The vector engine contains one arithmetic unit capable of four FP64 FMAs per cycle and a separate vector load and store unit. The resulting peak compute and memory throughput are listed in Table 1. Each core has 32 kiB of L1 data and 128 kiB of L2 cache, both of which operate with the same bandwidth of 256 bits per cycle or 55.9 GB/s. The L3 cache with a size of 2 MiB is shared between the four cores in a tile with a bandwidth of 25 GB/s per core. In Figure 1, the absolute time in seconds to compute a 1D DFT of given size N on a single core is plotted in a log-log scaling in the top plot. The relative speedup per transform size is shown in the bottom figure with logarithmic

Title Suppressed Due to Excessive Length

7

Table 1. Overview of the RISC-V CPUs under investigation. Bandwidth is bidirectional (read + write).

Core # Cores Frequency VLEN (DLEN) Peak FP64 (per core) L1 size L1 bandwidth (per core) L2 size L2 bandwidth (per core) L3 size L3 bandwidth (per core)

SiFive X280

SpacemiT K3

Sophon SG2044

SiFive X280 4 1.75 GHz 512 (256) bit 13.98 GLFOP/s 32 kiB (per core) 55.90 GB/s

X100 8 2.4 GHz 256 (128) bit 17.58 GLFOP/s 64 kiB (per core) 44.51 GB/s

C920v2 64 2.6 GHz 128 (128) bit 20.07 GLFOP/s 64 kiB (per core) 35.66 GB/s

128 kiB (per core) 55.82 GB/s

4 MiB (per 4 cores) 28.83 GB/s

2 MiB (per 2 cores) 28 GB/s

2 MiB (per 4 cores) 25.00 GB/s

n/a n/a

64 MiB (per 64 cores) 5.6 GB/s

scaling for the x-axis, with values greater than one indicating that juFFTe is faster than FFTW for given N . It can be seen that juFFTe outperforms FFTW consistently up to a size of N ≈ 16000, which corresponds to the limit of the L2 cache of 128 kiB as a complex double precision vector of length N takes 16N Bytes of memory. The reason for the superior performance of juFFTe over FFTW lies in the use of segmented vector load and store instructions, which perform particularly well on the SiFive X280 and yield more bandwidth than unit-stride memory operations. Once the bounds of the L2 cache are passed, juFFTe and FFTW exhibit similar levels of performance. As the memory latency increases significantly for accesses outside the L3 cache, the computations become memory-bound for large N and most time is spent waiting for data to arrive from and to DRAM. Despite lacking dedicated prefetching capabilities, the SiFive X280 benefits from packing routines part of the six-step algorithm implemented in juFFTe, which allow the computational kernels to stay in the L2 cache. As a result, juFFTe gains the lead for larger N as the additional costs of the packing procedures pay off. By enabling multi-threading with OpenMP, juFFTe and FFTW show similar levels of performance for larger N as can be seen from Figure 2, indicating that juFFTe could benefit from FFTW’s greater variety of parallelized FFT algorithms that are selected during its auto-tuning stage. Note that at the time of this writing, only four out of the 16 X280 cores present on the Blackhole device are accessible due to software limitations. SpacemiT K3 – X100: The SpacemiT K3 is a multi-core 64-bit RISC-V CPU featuring two types of cores, the X100 and the A100 [27]. The X100 is a fourissue out-of-order 64-bit RISC-V CPU based on the OpenC910 with a 256 bit vector length (VLEN) and 128 bit datapath length (DLEN). With two arithmetic units and two load/store units, the peak performance is four FP64 FMAs per cycle, see also Table 1. The L1 data cache of each X100 is 64 kiB big and four X100 share 4 MiB of L2 cache, which is the last level of cache. There are eight X100 and eight A100 cores present on the K3, making a total of 16 cores. Since

8

D. Seibel et al.

SiFive X280: Single core times of 1D c2c transforms 10 1

FFTW JUFFTE

time [s]

10 2 10 3 10 4 10 5 10 6 102

3.5

103

104 transform size N

105

106

SiFive X280: Single core speedup in 1D c2c transforms

3.0

speedup

2.5 2.0 1.5 1.0 0.5 0.0

FFTW JUFFTE speedup over FFTW 102

103

104 transform size N

105

106

Fig. 1. Execution times (top) and speedup (bottom) of juFFTe over FFTW on SiFive X280 with a single thread.

early testing revealed inferior performance for double precision computations compared to the X100 cores, the results for the A100 are omitted here. The K3 is not commercially available at the time of writing and the data presented here has been gathered on a cloud platform as part of the official beta test program. The relative speedup on a single core of juFFTe over FFTW for the SpacemiT X100 is visualized in Figure 3 with logarithmic scaling of the x-axis. Although FFTW is faster for very small N , juFFTe is more performant for sizes that almost fill up the L1 cache. In contrast to the SiFive X280, the advantage of segmented loads and stores disappears on the SpacemiT X100 and FFTW’s use of unit-stride memory instructions combined with dedicated in-lane shuffling for complex computations remains competitive. Within the limits of the L2 cache, FFTW has the upper hand as it deploys kernels of larger radix while juFFTe is limited to radices less than or equal to 16. The advantage of larger radices lies in the reduced number of total memory operations, which is critical as FFTs are usually memory bound. Although larger radices are technically feasible for juFFTe, the use of segmented instructions effectively doubles the number of vector registers in use, causing register spillage as only 32 vector registers are

Title Suppressed Due to Excessive Length 2.00

9

SiFive X280: Multi-core speedup in 1D c2c transforms FFTW JUFFTE speedup over FFTW

1.75

speedup

1.50 1.25 1.00 0.75 0.50 0.25 0.00 3 10

104

105 transform size N

106

Fig. 2. Speedup of juFFTe over FFTW on SiFive X280 with four threads.

SpacemiT K3 X100: Single core speedup in 1D c2c transforms

1.8 1.6

FFTW JUFFTE speedup over FFTW

1.4 speedup

1.2 1.0 0.8 0.6 0.4 0.0

102

103

104 transform size N

105

106

Fig. 3. Speedup of juFFTe over FFTW on SpacemiT X100 with a single thread.

available for RVV. For these reasons, it follows that juFFTe should incorporate the conventional vectorization strategy of using unit-stride loads and stores with shuffling instructions as an alternative in the future. For large N , the picture is mixed with juFFTe or FFTW being up to 80% faster depending on the particular N . In Figure 4, respective results for the multi-core case with eight cores are presented. Due to limited access time on the test system and the extensive overhead of FFTW’s auto-tuning with multi-threading, only heuristic planning has been invoked with FFTW_ESTIMATE. Therefore, juFFTe has a substantial lead over FFTW for larger N in L2 being almost 50% faster in most cases. Sophon SG2044: The Sophon SG2044 is a recent processor targeting highperformance computing applications. It is equipped with 64 Xuantie C920v2 cores, which are 12-stage out-of-order multiple issue superscalar 64-bit RISC-V CPUs [8]. In contrast to its predecessor, the SG2042, the SG2044 fully supports RVV 1.0 with a vector length of 128 bits (VLEN). The peak floating point

10

D. Seibel et al. 8

SpacemiT K3 X100: Multi-core speedup in 1D c2c transforms FFTW JUFFTE speedup over FFTW

7

speedup

6 5 4 3 2 1 0 3 10

104

105 transform size N

106

Fig. 4. Speedup of juFFTe over FFTW on SpacemiT X100 with eight threads.

performance of four FP64 FMAs per cycle indicates that two vector arithmetic units are present on each core. There are also two vector load/store units. Each core is equipped with 64 kiB of L1 data cache and four cores share 2 MiB of L2 cache. All cores share 64 MiB of L3 cache. The reported bandwidths in Table 1 are much lower than for the other two CPUs tested and are yet only obtainable for certain specific message sizes. This issue needs to be investigated further. At the time of submission, the SG2044 is the only commercially available server-grade RISC-V processor implementing the RVV 1.0 vector extension. All experiments and performance evaluations were conducted on the Monte Cimone cluster [35] using Sophon nodes equipped with the SG2044 processor.

12

Sophon SG 2044: Multi-core speedup in 1D c2c transforms FFTW JUFFTE speedup over FFTW

10

speedup

8 6 4 2 1 0

106

107

transform size N

108

109

Fig. 5. Speedup of juFFTe over FFTW on Sophon SG2044 with 64 threads.

Since the Sophon SG2044 features a high core count of 64 cores with 128 GB of DRAM, only the multi-core results are considered here, while single-core re-

Title Suppressed Due to Excessive Length

11

sults are summarized in Table 2. Figure 5 shows the relative speedup of juFFTe over FFTW against the transform size N in logarithmic scaling for the x-axis. Again due to limitations of FFTW’s auto-tuning, the setting has been set to FFTW_ESTIMATE to invoke heuristic planning. For every N benchmarked in the range from 106 to more than 109 , juFFTe computes DFTs faster than FFTW with an average speedup of 3x. This suggests that the six-step algorithm in juFFTe is especially effective for higher core counts in a shared-memory environment. Also, the use of packing and unpacking to keep DFT computations in L2 cache amortizes for large N as the number of data accesses per element increases with the transform size N .

Comparison against Zen 5: In order to understand how well these RVV 1.0 capable CPUs perform, a comparison against AMD‘s Zen 5 architecture is made. The Strix Point Zen 5 cores found in the HX 370 CPU are 8-wide out-of-order x64 CPUs that support the AVX-512 SIMD extension with a 256 bit datapath. The theoretical peak performance is about 8 FP64 FMAs per cycle or 82.5 GFLOP/s per core with a maximum core frequency of 5.16 GHz [37]. The cache bandwidth is 32 Bytes per cycle per core just as the SiFive X280, but due to the higher clock rate, the theoretical maximum bandwidth of the L1 (48 kiB) and L2 (1 MiB) cache is around 163 GB/s per core. The four Zen 5 cores in the HX 370 share 16 MiB of L3 cache with about half the theoretical bandwidth of the L1/L2 caches. Since the Zen 5 core can clock at much higher frequencies than the RISC-V CPUs, the maximum frequency is capped to 2.6 GHz to give a more indicative comparison. Nonetheless it should be noted that the HX370 is a mobile CPU with a similar TDP as the SiFive X280 and SpacemiT K3. Figure 6 compares the single-core performance of the RISC-V CPUs with the Zen 5 cores of the HX370. For each system, the plotted curve shows the point-wise minimum of the time-to-solution of juFFTe and FFTW on the Zen 5 core relative to RISC-V for given transform sizes N , i.e. tZen 5 /tRISC-V , again with logarithmic scaling for the x-axis. This ensures that the best possible FFT is chosen for every N . While the RISC-V CPUs all show a similar level of performance, the Zen 5 core is significantly faster throughout the entire range of transform sizes. Reasons for this are manifold as the Zen 5 cores have double the floating-point throughput of 16 FLOP per cycle, a higher cache bandwidth and a much more intricate front-end with powerful reordering capabilities and branch prediction. Nevertheless, the C920v2 core of the Sophon SG2044 and the SpacemiT X100 manage to attain about 15% of the performance of the Zen 5 core in average. The SiFive X280 core has difficulties keeping up for small and large N which can mostly be attributed to its comparatively low frequency and low DRAM bandwidth. These results demonstrate that the RISC-V ecosystem for high-performance computing still has room to catch up to established platforms like x86, but the emergence of RVV 1.0-capable hardware is an important step in the right direction, see also [8].

12

D. Seibel et al.

relative time (wrt HX370)

Relative single core times of 1D c2c transforms (vs HX370) Sophon SG2044 SiFive X280 SpacemiT K3 X100

0.25 0.20 0.15 0.10 0.05 104 103 transform size N

102

105

Fig. 6. Relative execution times tZen 5 /tRISC-V with a single thread.

6

Conclusion

As shown in Table 2, juFFTe can achieve considerable speedups over FFTW in single- and multi-core DFTs for RVV 1.0-enabled RISC-V CPUs. However, the performance evaluation also demonstrates that the optimization of FFT algorithms for RVV needs to take different vectorization strategies into account. RVV offers several ways of vectorizing DFT kernels due to its variety of special strided memory operations and permutation instructions, which perform differently depending on the hardware. A thorough analysis based on advanced roofline models is therefore needed to identify performance bottlenecks and adapt the vectorization to the capabilities of the hardware. For juFFTe, the authors aim to implement various vectorization strategies for RVV in combination with an auto-tuner similar to FFTW in order to attain high-performance for existing and future RISC-V hardware. Since auto-vectorization offered by compilers has shown to be unreliable in certain situations, the authors also plan to create a generator for DFT kernels in assembly with explicit RVV instructions to ensure maximum performance. Table 2. Best average speedup (single or multi-core) of juFFTe over FFTW.

Single-core avg. speedup Multi-core avg. speedup

SiFive X280

SpacemiT K3 X100

Sophon SG2044

1.53x 1.09x

0.90x 1.91x

0.73x 3.03x

Acknowledgments. The authors gratefully acknowledge the Monte Cimone project for providing access to the Sophon compute nodes used in this work. They thank SpacemiT and the RISC-V Ecological Application Innovation Center in Zhujiang for

Title Suppressed Due to Excessive Length

13

early access to the SpacemiT K3 via the remote beta test program. Funding for parts of this work has been received from EuroHPC’s project DARE SGA 1 under Grant Agreement No. 101202459.

References 1. DARE project, https://dare-riscv.eu/ 2. EUPILOT project, https://eupilot.eu/ 3. Oscpu/nutshell: Risc-v soc designed by students in ucas, https://github.com/ OSCPU/NutShell 4. Xuantie, https://www.xrvm.com/product/xuantie/C910 5. Abraham, M.J., Gready, J.E.: Optimization of parameters for molecular dynamics simulation using smooth particle-mesh ewald in gromacs 4.5. Journal of computational chemistry 32(9), 2031–2040 (2011) 6. Asanović, K., Bodik, R., Catanzaro, B.C., Gebis, J.J., Husbands, P., Keutzer, K., Patterson, D.A., Plishker, W.L., Shalf, J., Williams, S.W., Yelick, K.A.: The landscape of parallel computing research: A view from berkeley. Tech. Rep. UCB/EECS-2006-183 (Dec 2006), http://www2.eecs.berkeley.edu/Pubs/ TechRpts/2006/EECS-2006-183.html 7. Bailey, D.H.: The nas parallel benchmarks. Tech. rep., Ernest Orlando Lawrence Berkeley National Laboratory, Berkeley, CA (US) (11 2009). https://doi.org/10. 2172/983318 8. Brown, N.: Is RISC-V ready for high performance computing? An evaluation of the Sophon SG2044. Proceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis pp. 1703–1711 (11 2025). https://doi.org/10.1145/3731599.3767531 9. Buchheit, A.A., Keßler, T., Schuhmacher, P.K., Fauseweh, B.: Exact continuum representation of long-range interacting systems and emerging exotic phases in unconventional superconductors. Phys. Rev. Res. 5, 043065 (Oct 2023). https: //doi.org/10.1103/PhysRevResearch.5.043065 10. Colella, P.: Defining software requirements for scientific computing (2004) 11. Cooley, J.W., Tukey, J.W.: An algorithm for the machine calculation of complex fourier series. Mathematics of Computation 19, 297–301 (1965) 12. Dolbeau, R.: FFTW3 with RVV 1.0 support. https://github.com/rdolbeau/fftw3/ tree/riscv-v-clean (2025), gitHub repository; accessed 2026-03-31 13. Franchetti, F., Low, T.M., Popovici, D.T., Veras, R.M., Spampinato, D.G., Johnson, J.R., Püschel, M., Hoe, J.C., Moura, J.M.F.: Spiral: Extreme performance portability. Proceedings of the IEEE 106(11), 1935–1968 (2018). https://doi.org/ 10.1109/JPROC.2018.2873289 14. Frigo, M., Johnson, S.G.: The design and implementation of FFTW3. Proceedings of the IEEE 93(2), 216–231 (2005). https://doi.org/10.1109/JPROC.2004.840301, special issue on “Program Generation, Optimization, and Platform Adaptation” 15. Giannozzi, P., Andreussi, O., Brumme, T., Bunau, O., Buongiorno Nardelli, M., Calandra, M., Car, R., Cavazzoni, C., Ceresoli, D., Cococcioni, M., Colonna, N., Carnimeo, I., Dal Corso, A., de Gironcoli, S., Delugas, P., DiStasio, R.A., Ferretti, A., Floris, A., Fratesi, G., Fugallo, G., Gebauer, R., Gerstmann, U., Giustino, F.,

14

D. Seibel et al.

Gorni, T., Jia, J., Kawamura, M., Ko, H.Y., Kokalj, A., Küçükbenli, E., Lazzeri, M., Marsili, M., Marzari, N., Mauri, F., Nguyen, N.L., Nguyen, H.V., Otero-de-la Roza, A., Paulatto, L., Poncé, S., Rocca, D., Sabatini, R., Santra, B., Schlipf, M., Seitsonen, A.P., Smogunov, A., Timrov, I., Thonhauser, T., Umari, P., Vast, N., Wu, X., Baroni, S.: Advanced capabilities for materials modelling with quantum espresso. Journal of Physics: Condensed Matter 29(46), 465901 (oct 2017). https: //doi.org/10.1088/1361-648X/aa8f79 16. Intel Corporation: Intel 64 and IA-32 Architectures Software Developer’s Manual. Intel (2024), https://www.intel.com/content/www/us/en/developer/articles/ technical/intel-sdm.html 17. Jiang, L., Xu, S., Liu, Y., Shen, Y., Shi, Y., Cao, S., Jiang, Z.: An arbitrary register grouping scheme for risc-v vector extension: Compilation support and hardware implementation. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems pp. 1–1 (2025). https://doi.org/10.1109/TCAD.2025.3649448 18. Jiang, S., Zou, Y., Wang, H., Li, W.: An fft accelerator using deeply-coupled risc-v instruction set extension for arbitrary number of points. In: 2023 IEEE 34th International Conference on Application-specific Systems, Architectures and Processors (ASAP). pp. 165–171 (2023). https://doi.org/10.1109/ASAP57973.2023.00036 19. Kabel, M., Böhlke, T., Schneider, M., Kabel, M., Böhlke, T., Schneider, M.: Efficient fixed point and newton–krylov solvers for fft-based homogenization of elasticity at large deformations. Computational Mechanics 2014 54:6 54, 1497–1514 (10 2014). https://doi.org/10.1007/s00466-014-1071-8 20. Perotti, M., Cavalcante, M., Andri, R., Cavigelli, L., Benini, L.: Ara2: Exploring single- and multi-core vector processing with an efficient rvv 1.0 compliant opensource processor. IEEE Transactions on Computers 73, 1822–1836 (7 2024). https: //doi.org/10.1109/TC.2024.3388896 21. Petersen, H.G.: Accuracy and efficiency of the particle mesh ewald method. The Journal of chemical physics 103(9), 3668–3679 (1995) 22. Proakis, J.G., Monolakis, D.G.: Digital signal processing: principles, algorithms, and applications. Prentice-Hall, 3 edn. (2 1996) 23. Reddy, B., Chatterji, B.: An fft-based technique for translation, rotation, and scaleinvariant image registration. IEEE Transactions on Image Processing 5(8), 1266– 1271 (1996). https://doi.org/10.1109/83.506761 24. RISC-V International: The risc-v vector extension, version 1.0. Tech. Rep. v1.0, RISC-V International (2021), https://github.com/riscv/riscv-v-spec/releases 25. RISC-V International: Rva23 profile release. Tech. rep., RISC-V International (2024), https://docs.riscv.org/reference/rva23/_attachments/rva23-profile.pdf 26. Seibel, D.: Boundary element methods for the wave equation based on hierarchical matrices and adaptive cross approximation. Numer. Math. 150(2), 629–670 (2022) 27. SpacemiT: SpacemiT K3: A RVA23 RISC-V AI CPU with 60 TOPS AI Compute. Preprint (jan 2026), https://forum.spacemit.com/uploads/short-url/ 60aJ8cYNmrFWqHn4ddwwSzMLjlY.pdf, preprint. Accessed via forum upload 28. Stockham, T.G.: High-speed convolution and correlation. In: Proceedings of the Spring Joint Computer Conference. AFIPS Conference Proceedings, vol. 28, pp. 229–233. Spartan Books (1966) 29. Strack, A., Taylor, C., Pflüger, D.: Parallel fftw on risc-v: A comparative study including openmp, mpi, and hpx. In: Neuwirth, S., Paul, A.K., Weinzierl, T., Carson, E.C. (eds.) High Performance Computing. pp. 586–597. Springer Nature Switzerland, Cham (2026)

Title Suppressed Due to Excessive Length

15

30. Takahashi, D., Franchetti, F.: FFTE on SVE: SPIRAL-generated kernels. In: Proceedings of the International Conference on High Performance Computing in AsiaPacific Region. p. 114–122. HPCAsia ’20, Association for Computing Machinery, New York, USA (2020). https://doi.org/10.1145/3368474.3368488 31. Takahashi, D.: Fast Fourier Transform Algorithms for Parallel Computers. Springer Singapore, 1 edn. (2019). https://doi.org/10.1007/978-981-13-9965-7 32. Takahashi, D.: FFTE: A fast fourier transform package (2020) 33. Tolmachev, D.: Vkfft-a performant, cross-platform and open-source gpu fft library. IEEE Access 11 (2023). https://doi.org/10.1109/ACCESS.2023.3242240 34. Van Loan, C.: Computational frameworks for the fast Fourier transform, Frontiers in Applied Mathematics, vol. 10. Society for Industrial and Applied Mathematics (SIAM), Philadelphia, PA (1992). https://doi.org/10.1137/1.9781611970999 35. Venieri, E., Manoni, S., Ceccolini, G., Madella, G., Ficarelli, F., Gregori, D., Acquaviva, A., Benini, L., Bartolini, A.: Monte Cimone v2: HPC RISC-V Cluster Evaluation and Optimization, vol. 16091 LNCS, pp. 576–585. Springer Science and Business Media Deutschland GmbH (2026). https://doi.org/10.1007/ 978-3-032-07612-0_44 36. Vizcaino, P., Mantovani, F., Ferrer, R., Labarta, J.: Acceleration with long vector architectures: Implementation and evaluation of the fft kernel on nec sx-aurora and risc-v vector extension. Concurrency and computation: practice and experience 35(20, article e7424) (Sept 2023). https://doi.org/10.1002/cpe.7424 37. Yee, A.J.: Zen5’s avx512 teardown + more... (Aug 2024), https://www. numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/, blog post; last updated March 14, 2025 38. Zhao, X., Zhang, X., Zhang, Y.: Optimization of the fft algorithm on risc-v cpus. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 13999 LNCS, 515–525 (2023). https://doi.org/10.1007/978-3-031-40843-4_38

Related documents

• Performance Evaluation of Fast Fourier Transforms on Emerging RISC-V Hardware with Vector Extension Support#784839
• Performance Evaluation of Fast Fourier Transforms on Emerging RISC-V Hardware with Vector Extension Support#783249
• ARCHITECTURAL SUPPORT FOR ENCRYPTED INSTRUCTION EXECUTION IN A SECURE RISC-V PROCESSOR#674656
• IKEv2 Extensions to Support Robust Header Compression over IPsec#501236
• Transmission and Processing of IPv6 Extension Headers#501850