Parallel FFTW on RISC-V: A Comparative Study including OpenMP, MPI, and HPX

Alexander Strack; Christopher Taylor; Dirk Pfl\"uger

REVIEW 2 major objections 5 minor 24 references

Parallel FFTW on RISC-V: A Comparative Study including OpenMP, MPI, and HPX

T0 review · 2 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read FFTW's MPI backend scales to 64 cores on RISC-V regardless of planning, while the OpenMP backend needs measured planning to avoid a steep drop at 64 cores; the SG2042 RISC-V chip trails a 64-core AMD EPYC by about a factor of eight on…

desk verdict Useful first parallel FFTW scaling datapoint on 64-core RISC-V, but the factor-8 gap vs EPYC is confounded by an unstated SIMD asymmetry. read the letter →

arxiv 2506.08653 v1 pith:CTKWL67Y submitted 2025-06-10 cs.DC cs.ET

Alexander Strack , Christopher Taylor , Dirk Pflüger This is my paper

classification cs.DCcs.ET

keywords FFTWRISC-VOpenMPMPIHPXfastFouriertransformSG2042strongscaling

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper evaluates how well the FFTW library can parallelize a double-precision 2D FFT on 64-core hardware, comparing the SG2042 RISC-V chip against an AMD EPYC 7742 x86-64 chip. The main finding is a robust asymmetry between FFTW's two parallelization backends: the MPI backend scales cleanly to 64 cores on both architectures regardless of planning mode, while the OpenMP backend suffers a sharp performance drop at 64 cores unless the user switches from estimated to measured planning. Across all benchmarks, the RISC-V chip trails x86-64 by about a factor of eight. The authors also show that HPX-FFT, an asynchronous task-based FFT library, is fastest on x86-64 but its memory-access optimizations fail to help on the SG2042, and they recommend FFTW with MPI as the current best choice for parallel FFT on many-core RISC-V.

What carries the argument

The load-bearing mechanism is FFTW's planning system, which selects the best combination of generated FFT codelets for a given size and machine; the paper contrasts estimated plans (heuristic, fast to produce) with measured plans (benchmarked on the actual hardware). The work also centers on FFTW's two parallel backends: MPI, which distributes a 2D transform via all-to-all transposes, and OpenMP, which schedules shared-memory threads. HPX-FFT, built on the HPX runtime with FFTW as its 1D FFT backend, serves as the third comparison point and as a probe for memory-access optimization. The benchmark workload is the standard four-step transpose-based 2D FFT (real-to-complex transform, transpose, complex-to-complex transform, transpose), which exposes where each architecture spends its time.

What would settle it

Re-run the $2^{14}\times2^{14}$ FP64 2D FFT on the SG2042 with an FFTW build that vectorizes for RVV0.7.1 and on the EPYC with AVX2 disabled; if the factor-8 gap narrows materially, the headline gap was partly an artifact of asymmetric SIMD settings, and if it stays near 8, the gap is in the cores and memory system.

Watch

Extended reading notes

Core claim

The paper's central discovery is that FFTW's planning mode and parallelization backend interact to determine whether a 64-core RISC-V system can actually be used. With estimated planning, FFTW's OpenMP backend shows a large performance drop at 64 cores on both x86-64 and RISC-V; measured planning repairs this, giving average speedups of 3.12 and 7.51 respectively over estimated planning. The MPI backend, in contrast, scales well up to 64 cores with either planning mode, and gains only modestly from measured planning (1.27 on x86-64, 1.13 on RISC-V). On the RISC-V side, the paper finds that HPX-FFT stops scaling beyond roughly 16 cores and that its carefully tuned memory-access optimizations, which pay off on x86-64, have little effect on the SG2042. The authors interpret this as evidence that the SG2042's limiting factor is memory and cache behavior, not the FFT arithmetic: at 64 cores, the transpose steps consume about 90% of the runtime on RISC-V.

Load-bearing premise

The factor-eight comparison assumes the runs were fair: RISC-V was compiled without vectorization because the FFTW release targets RVV1.0, while the x86-64 side kept AVX2 enabled, so if SIMD accounts for part of the gap, the RISC-V chip's core and memory disadvantage is overstated.

Editorial extensions

If this is right

For today's many-core RISC-V systems, FFTW with MPI is the recommended parallelization: it scales to 64 cores with either estimated or measured planning, while OpenMP at 64 cores collapses unless planning is measured.
Measured planning is effectively mandatory for the OpenMP backend at 64 cores: it produced an average 3.12x speedup on x86-64 and 7.51x on RISC-V versus estimated planning, restoring good scaling on both chips.
HPX-FFT's memory-access optimizations (blocked transposes, cache-aware schedules) do not transfer to RISC-V: they give large gains on x86-64 but barely move the SG2042, which stops scaling beyond about 16 cores.
The SG2042's bottleneck for this workload is memory and cache behavior rather than FFT arithmetic: the transpose share of runtime grows from 70% at 16 cores to 90% at 64 cores.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A testable extension of the paper's recommendation: on the SG2042, pinning OpenMP threads to physical cores or using one MPI rank per 4-core cluster (16 ranks, 4 threads each) may recover the OpenMP drop seen with estimated planning, since the measured-planning speedup hints that thread placement, not the FFT math, is the failure point.
If the factor-8 gap is read as mostly memory-bound, a bandwidth-focused optimization, such as blocking the transpose for the SG2042's 1 MB per-cluster L2, could be a better RISC-V target than vectorizing the FFT kernels.
Combining the paper's runtimes with the chips' 120 W vs 225 W TDPs would convert the factor-8 runtime gap into a roughly factor-15 performance-per-watt gap, the metric that matters most for HPC procurement.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the short version: this is a genuinely useful benchmark paper—the first side-by-side parallel 2D FFTW comparison on the 64-core SG2042 against a 64-core EPYC 7742. The finding that measured planning fixes the OpenMP scaling collapse at 64 cores on both architectures is real and worth knowing. The MPI recommendation for many-core RISC-V systems is plausible on the presented data. The paper is also careful about its methods: median-of-10 runtimes, min/max bars, reruns on both machines with matched software versions, and the benchmark scripts are on DaRUS.

The soft spot is the headline. Section 5.2 says vectorization is not considered 'for better comparability,' and the RISC-V side ran scalar FFTW because the release targets RVV1.0 while SG2042 has RVV0.7.1. But the paper never states whether the EPYC side also ran with SIMD disabled. The hardware table lists AVX2 for the EPYC. If the EPYC ran with AVX2, the factor-8 performance delta mixes ISA vectorization with core and memory performance. That's a real confound, and the abstract and conclusion state 'factor eight' without this caveat. The within-architecture comparisons—MPI vs OpenMP, estimated vs measured planning, HPX-FFT optimization levels—are unaffected because they compare apples to apples within each chip. So the main recommendation survives, but the cross-architecture number needs to be reworded or re-benchmarked properly (e.g., scalar-on-both or RVV0.7.1-on-both).

There are minor limitations too: a single problem size, a single RISC-V chip, and the OpenMP measured-planning speedup is large but based on one configuration. These are normal for a first datapoint. The citation pattern looks fine; the self-cited prior HPX-FFT work is the natural reference for the optimization variants, and all benchmarks were rerun.

Who should read this: anyone making early RISC-V software choices for HPC, or anyone tracking SG2042 performance. It deserves a serious referee; the SIMD configuration needs to be clarified before the factor-8 claim is taken at face value.

Referee Report

2 major / 5 minor

Summary. The paper evaluates parallel FFT performance on a 64-core SOPHON SG2042 RISC-V chip against a 64-core AMD EPYC 7742, using FFTW with MPI, OpenMP, and MPI+OpenMP backends, plus HPX-FFT variants with different memory-access optimizations. The benchmark is a strong-scaling 2^14 x 2^14 double-precision 2D FFT from 1 to 64 cores, with estimated and measured FFTW planning, reporting median-of-10 runtimes with min/max error bars. The central claims are that (1) the RISC-V chip trails x86-64 by roughly a factor of eight, (2) FFTW with MPI scales well on both architectures regardless of planning, (3) the OpenMP backend requires measured planning to avoid a large drop at 64 cores, and (4) HPX-FFT memory optimizations that help on x86-64 do not transfer to RISC-V. The paper recommends FFTW with MPI for current many-core RISC-V systems.

Significance. If the results hold, this is a useful early data point for the RISC-V HPC software stack: it is, to the authors' knowledge, the first side-by-side parallel FFT comparison on x86-64 and RISC-V at 64 cores, and it provides reproducible benchmark code and scripts on DaRUS. The within-architecture findings, especially the measured-planning effect for the OpenMP backend and the consistent MPI scaling, are directly actionable for practitioners. The paper also carefully reruns the x86-64 benchmarks with software versions matching the RISC-V system rather than reusing prior results. The main caveat is that the headline factor-eight architecture gap is potentially confounded by an unstated SIMD asymmetry, which limits the strength of the cross-architecture quantitative claim until the build configurations are clarified or matched.

major comments (2)

[Section 5.2, Table 1, Conclusion] The factor-eight performance delta stated in the abstract and conclusion is not a clean architecture comparison because the SIMD configuration is asymmetric. Section 5.2 states that RISC-V vectorization is skipped because the FFTW release targets RVV1.0 while the SG2042 implements RVV0.7.1, but the paper never states whether the EPYC 7742 FFTW build had AVX2 enabled. Table 1 lists AVX2 on the EPYC, and a standard FFTW build enables it by default. If AVX2 was enabled, the 2-4x vectorization advantage on the EPYC is folded into the 'factor eight' claim, and the conclusion's 'performance delta of around factor eight averaged over all FFT benchmarks' overstates the RISC-V cores and memory system. Please report the exact FFTW build flags for both machines and either disable SIMD on the EPYC, enable RVV0.7.1 through the patch in [3], or present both vectorized and scalar results so the hardware gap can be separated from ISA vectorization.
[Sections 5.1, 5.2, and Conclusion] The headline 'factor eight' is not well-defined. Section 5.2 reports a delta of 4.0 to 8.0 for parallel FFTW, while Section 5.1 reports factors of 5.6 (naive HPX-FFT) and 10.7 (opt/sync/for_loop) at up to 16 cores. The conclusion states a delta 'averaged over all FFT benchmarks,' but no averaging procedure (arithmetic mean, geometric mean, range, or at which core count) is given, and the range across configurations makes a single factor misleading. Please report the per-implementation, per-core-count deltas and state how the average was computed.

minor comments (5)

[Section 4.1] The name 'Cooley and Turkey' should be 'Cooley and Tukey'.
[Table 1] The SIMD row for RISC-V lists RVV0.7.1, but Section 5.2 says FFTW ran without vectorization; add a note that the hardware SIMD is unused in the FFTW benchmarks to avoid confusion.
[Section 5.3] The statement 'the lack of a cycle counter makes efficient planning impossible' should specify whether this applies to the standard FFTW release and how the RISC-V release provides the cycle counter; also state the exact FFTW version or commit used on each machine.
[Section 5.2] The phrase 'we do not consider vectorization for better comparability' is ambiguous because the x86-64 side likely uses AVX2; clarify that comparability refers to the RISC-V FFTW release's RVV1.0 target versus the SG2042's RVV0.7.1, and state whether the x86-64 build used SIMD.
[Section 5.1] The sentence 'For more than 32 cores, the performance of all implementations is significantly reduced' appears in a paragraph that switches between x86-64 and RISC-V; specify that this refers to the RISC-V machine.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are empirical benchmark results rerun for this study, not derived from fitted inputs or self-cited predictions.

full rationale

The paper is an empirical benchmark study. Its central claims—MPI scaling well to 64 cores regardless of planning, OpenMP needing measured planning, and an approximately factor-eight performance gap between the SG2042 and the EPYC 7742—are direct measurements of rerun experiments on both machines. The self-citations to the authors' prior HPX-FFT work [20] supply the implementation variants and optimization categories, but Section 5 explicitly states 'The results of our previous work are not reused. Instead, we rerun the benchmarks on the x86-64 system with software versions that match the RISC-V system.' No fitted parameter is renamed as a prediction, no result is defined in terms of another result, and no load-bearing claim rests on an unverified self-citation. The cited external work (Brown et al. [2], Cai [3]) is used as related work or context, not as the proof of this paper's conclusions. The potential concern that the factor-eight comparison may be confounded by unstated SIMD asymmetry—RISC-V vectorization disabled while x86-64 uses AVX2—is a question of experimental fairness and external validity, not circularity, since the numbers are still measured rather than assumed. Accordingly, the circularity score is 0.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The paper has no fitted model parameters; the only hand-chosen quantity is the benchmark problem size. The assumptions that matter for the central claims are the fairness of the core-count comparison, the equivalence of the FFTW fork used on RISC-V, and the interpretation of runtime breakdowns as memory-access costs. No new entities are introduced.

free parameters (1)

Benchmark problem size = 2^14 x 2^14 FP64 (16,384 x 16,384)
A single problem size and precision were chosen for all scaling tests; conclusions about the RISC-V performance gap and MPI scaling may be size-dependent and were not tested across sizes.

assumptions (3)

domain assumption Core parity (64 cores vs 64 cores) is the right fairness baseline for comparing the two architectures.
The comparison treats one core of each architecture as equivalent in Section 5, though the chips differ in SIMD width, cache hierarchy, and memory bandwidth. The 8x gap is presented as an architecture-level result without adjusting for these factors.
domain assumption The RISC-V FFTW fork implements the same planning semantics as upstream FFTW.
Measured planning on RISC-V required a patched release with cycle-counter support (Section 5.3); the paper assumes its plans are comparable to the standard FFTW plans used on x86-64.
domain assumption Runtime breakdown reflects memory-access cost rather than other overheads.
Figures 4 and 5 attribute the transpose phase to memory inefficiency, but no hardware counters or bandwidth measurements are provided; synchronization or scheduling effects could also contribute.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Parallel FFTW on RISC-V: A Comparative Study including OpenMP, MPI, and HPX." pith.science (2026). https://pith.science/paper/CTKWL67Y

@misc{pith2026250608653,
  author       = {Pith},
  title        = {Pith review of: Parallel FFTW on RISC-V: A Comparative Study including OpenMP, MPI, and HPX},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CTKWL67Y}},
  note         = {Machine review of arXiv:2506.08653}
}

read the original abstract

Rapid advancements in RISC-V hardware development shift the focus from low-level optimizations to higher-level parallelization. Recent RISC-V processors, such as the SOPHON SG2042, have 64 cores. RISC-V processors with core counts comparable to the SG2042, make efficient parallelization as crucial for RISC-V as the more established processors such as x86-64. In this work, we evaluate the parallel scaling of the widely used FFTW library on RISC-V for MPI and OpenMP. We compare it to a 64-core AMD EPYC 7742 CPU side by side for different types of FFTW planning. Additionally, we investigate the effect of memory optimization on RISC-V in HPX-FFT, a parallel FFT library based on the asynchronous many-task runtime HPX using an FFTW backend. We generally observe a performance delta between the x86-64 and RISC-V chips of factor eight for double-precision 2D FFT. Effective memory optimizations in HPX-FFT on x86-64 do not translate to the RISC-V chip. FFTW with MPI shows good scaling up to 64 cores on x86-64 and RISC-V regardless of planning. In contrast, FFTW with OpenMP requires measured planning on both architectures to achieve good scaling up to 64 cores. The results of our study mark an early step on the journey to large-scale parallel applications running on RISC-V.

Figures

Figures reproduced from arXiv: 2506.08653 by the authors.

**Figure 2.** Strong scaling runtimes of different optimizations on up to 64 x86-64 cores for a 214 × 2 14 FFT using HPXFFT. 1 2 4 8 16 32 64 N cores 10 1 10 0 10 1 10 2 10 3 Runtime in s HPX-FFT naive HPX-FFT opt HPX-FFT sync HPX-FFT for_loop [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

**Figure 4.** Partial runtimes of HPX-FFT for loop on up to 64 x86-64 cores for a 2 14 × 2 14 FFT. 1 2 4 8 16 32 64 N cores 10 1 10 0 10 1 10 2 10 3 Runtime in s First FFT (r2c) First Transpose Second FFT (c2c) Second Transpose [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗

Figures from the paper (2 more)

**Figure 6.** Figure 6: Strong scaling runtimes on up to 64 x86-64 cores for a 214 × 2 14 FFT using FFTW with estimated planning. The execution configuration is represented as (#processes/#threads). 1 2 4 8 16 32 64 N cores 10 1 10 0 10 1 10 2 10 3 Runtime in s FFTW3 MPI (1-64/1) FFTW3 MPI+O…

**Figure 8.** Figure 8: Strong scaling runtimes on up to 64 x86-64 cores for a 214 × 2 14 FFT using FFTW with measured planning. The execution configuration is represented as (#processes/#threads). 1 2 4 8 16 32 64 N cores 10 1 10 0 10 1 10 2 Runtime in s FFTW3 MPI (1-64/1) FFTW3 MPI+OpenMP …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages

[3]

Master’s thesis, Universidad Complutense de Madrid, Madrid (2024)

Cai, J.: Performance evaluation of numerical libraries on RISC-V architectures with SIMD extensions. Master’s thesis, Universidad Complutense de Madrid, Madrid (2024)

work page 2024
[1]

al.: FFT benchmark performance experimentson systems targeting exascale

Ayala, A., et. al.: FFT benchmark performance experimentson systems targeting exascale. Tech. rep., University of Tennessee (2022)

work page 2022
[2]

In: SC-W 2023

Brown, N., Jamieson, M., Lee, J., Wang, P.: Is RISC-V ready for HPC prime- time: Evaluating the 64-core Sophon SG2042 RISC-V CPU. In: SC-W 2023. p. 1566–1574. SC-W 2023, ACM (Nov 2023)

work page 2023
[4]

Mathematics of Computation19(90), 297–301 (1965) 8 https://doi.org/10.18419/DARUS-5056 (accessed on 05/16/2025) 12 A

Cooley, J., Tukey, J.: An algorithm for the machine calculation of complex fourier series. Mathematics of Computation19(90), 297–301 (1965) 8 https://doi.org/10.18419/DARUS-5056 (accessed on 05/16/2025) 12 A. Strack, et. al

work page doi:10.18419/darus-5056 1965
[5]

IEEE Computational Science and Engineering5(1), 46–55 (1998)

Dagum, L., Menon, R.: OpenMP: an industry standard API for shared-memory programming. IEEE Computational Science and Engineering5(1), 46–55 (1998)

work page 1998
[6]

Deserno, M., Holm, C.: How to mesh up Ewald sums. I. A theoretical and numerical comparison of various particle mesh routines. J. Chem. Phys.109(18), 7678–7693 (11 1998)

work page 1998
[7]

In: SC-W 2023

Diehl, P., et al.: Evaluating HPX and Kokkos on RISC-V using an astrophysics application Octo-Tiger. In: SC-W 2023. p. 1533–1542. Association for Computing Machinery, New York, NY, USA (2023)

work page 2023
[8]

In: SC-W 2024

Diehl, P., et al.: Preparing for HPC on RISC-V: Examining Vectorization and Distributed Performance of an Astrophysics Application with HPX and Kokkos. In: SC-W 2024. p. 1656–1665. IEEE (Nov 2024)

work page 2024

Show all 24 references

[9]

Proceedings of the IEEE93(2), 216–231 (2005)

Frigo, M., Johnson, S.: The Design and Implementation of FFTW3. Proceedings of the IEEE93(2), 216–231 (2005)

2005
[10]

al.: Open MPI: Goals, concept, and design of a next generation MPI implementation

Gabriel, E., et. al.: Open MPI: Goals, concept, and design of a next generation MPI implementation. In: Proceedings, 11th European PVM/MPI Users’ Group Meeting. pp. 97–104. Budapest, Hungary (September 2004)

2004
[11]

al.: Accfft: A library for distributed-memory FFT on CPU and GPU architectures

Gholami, A., et. al.: Accfft: A library for distributed-memory FFT on CPU and GPU architectures. CoRR (2015)

2015
[12]

MIT Press, 2 edn

Gropp, W., Lusk, E., Skjellum, A.: Using MPI: Portable Parallel Programming with the Message Passing Interface. MIT Press, 2 edn. (1999)

1999
[13]

Technical report, Lawrence Livermore National Laboratory (LLNL), Livermore, CA, United States (2017)

Hornung, R.D., Jones, H.E.: RAJA Performance Suite. Technical report, Lawrence Livermore National Laboratory (LLNL), Livermore, CA, United States (2017)

2017
[14]

Journal of Open Source Software5(53), 2352 (2020)

Kaiser, H., Diehl, P., Lemoine, A.S., Lelbach, B.A., Amini, P., Berge, A., Bid- discombe, J., Brandt, S.R., Gupta, N., Heller, T., et al.: HPX-the C++standard library for parallelism and concurrency. Journal of Open Source Software5(53), 2352 (2020)

2020
[15]

In: PPoPP ’23

Li, Z., et al.: Generating fast fft kernels on cpus via fft-specific intrinsics. In: PPoPP ’23. p. 427–428. Association for Computing Machinery, New York, NY, USA (2023)

2023
[16]

Marcello, D.C., et al.: Octo-Tiger: a new, 3D hydrodynamic code for stellar mergers that uses HPX parallelization. Mon. Notices Royal Astron. Soc.504(4), 5345–5382 (04 2021)

2021
[17]

Message Passing Interface Forum: MPI: A Message-Passing Interface Standard Version 3.0 (2021)

2021
[18]

SISC34(4), C192–C209 (2012)

Pekurovsky, D.: P3dfft: A framework for parallel computations of fourier trans- forms in three dimensions. SISC34(4), C192–C209 (2012)

2012
[19]

In: Euro-Par 2024: Parallel Processing Workshops

Strack, A., Pfl¨ uger, D.: A HPX Communication Benchmark: Distributed FFT using Collectives. In: Euro-Par 2024: Parallel Processing Workshops. Lecture Notes in Computer Science, Springer (2025)

2025
[20]

Strack, A., Taylor, C., Diehl, P., Pfl¨ uger, D.: Experiences Porting Shared and Distributed Applications to Asynchronous Tasks: A Multidimensional FFT Case- Study, p. 111–122. Springer Nature Switzerland (2024)

2024
[21]

Con- currency and Computation: Practice and Experience35(11 2022)

Vizcaino, P., et al.: Acceleration with long vector architectures: Implementation and evaluation of the fft kernel on nec sx-aurora and risc-v vector extension. Con- currency and Computation: Practice and Experience35(11 2022)

2022
[22]

Technical Report 2, University of California, Berkeley (2014)

Waterman, A., et al.: The RISC-V Instruction Set Manual, Volume I: User-Level ISA. Technical Report 2, University of California, Berkeley (2014)

2014
[23]

In: Proceedings of the SC ’23 Workshops

Yan, J., Kaiser, H., Snir, M.: Design and Analysis of the Network Software Stack of an Asynchronous Many-task System – The LCI parcelport of HPX. In: Proceedings of the SC ’23 Workshops. p. 1151–1161. ACM, New York, NY, USA (2023)

2023
[24]

In: ISC HP 2023 Workshopss

Zhao, X., Zhang, X., Zhang, Y.: Optimization of the fft algorithm on risc-v cpus. In: ISC HP 2023 Workshopss. p. 515–525. Springer-Verlag, Berlin, Heidelberg (2023)

2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [3]

Master’s thesis, Universidad Complutense de Madrid, Madrid (2024)

Cai, J.: Performance evaluation of numerical libraries on RISC-V architectures with SIMD extensions. Master’s thesis, Universidad Complutense de Madrid, Madrid (2024)

work page 2024

[2] [1]

al.: FFT benchmark performance experimentson systems targeting exascale

Ayala, A., et. al.: FFT benchmark performance experimentson systems targeting exascale. Tech. rep., University of Tennessee (2022)

work page 2022

[3] [2]

In: SC-W 2023

Brown, N., Jamieson, M., Lee, J., Wang, P.: Is RISC-V ready for HPC prime- time: Evaluating the 64-core Sophon SG2042 RISC-V CPU. In: SC-W 2023. p. 1566–1574. SC-W 2023, ACM (Nov 2023)

work page 2023

[4] [4]

Mathematics of Computation19(90), 297–301 (1965) 8 https://doi.org/10.18419/DARUS-5056 (accessed on 05/16/2025) 12 A

Cooley, J., Tukey, J.: An algorithm for the machine calculation of complex fourier series. Mathematics of Computation19(90), 297–301 (1965) 8 https://doi.org/10.18419/DARUS-5056 (accessed on 05/16/2025) 12 A. Strack, et. al

work page doi:10.18419/darus-5056 1965

[5] [5]

IEEE Computational Science and Engineering5(1), 46–55 (1998)

Dagum, L., Menon, R.: OpenMP: an industry standard API for shared-memory programming. IEEE Computational Science and Engineering5(1), 46–55 (1998)

work page 1998

[6] [6]

Deserno, M., Holm, C.: How to mesh up Ewald sums. I. A theoretical and numerical comparison of various particle mesh routines. J. Chem. Phys.109(18), 7678–7693 (11 1998)

work page 1998

[7] [7]

In: SC-W 2023

Diehl, P., et al.: Evaluating HPX and Kokkos on RISC-V using an astrophysics application Octo-Tiger. In: SC-W 2023. p. 1533–1542. Association for Computing Machinery, New York, NY, USA (2023)

work page 2023

[8] [8]

In: SC-W 2024

Diehl, P., et al.: Preparing for HPC on RISC-V: Examining Vectorization and Distributed Performance of an Astrophysics Application with HPX and Kokkos. In: SC-W 2024. p. 1656–1665. IEEE (Nov 2024)

work page 2024