REVIEW 4 major objections 5 minor 8 references
Exploring Fast Fourier Transforms on the Tenstorrent Wormhole
T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash
Pith's one-line read RISC-V accelerator cuts FFT energy 3.6x vs Xeon CPU
desk verdict First FFT port to a Tenstorrent Wormhole with a plausible but under-supported energy-efficiency claim; the n300 measurements look careful, the CPU baseline does not. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central object is the Tensix core, a tile containing five RISC-V 'baby' cores (one for moving data in, one for moving data out, three driving a compute engine), 1.3 MB of local SRAM, and circular buffers (FIFOs) that hold data pages and synchronize producer-consumer behaviour between cores. The FFT kernel works with real and imaginary components separately and uses the SFPU vector unit; the paper reduces data movement by reordering once per FFT step instead of twice, and offloads copies to the ThCon scalar unit using 128-bit loads where accesses are contiguous. These pieces together determine whether the accelerator's decoupling of data movement from compute can compensate for its raw speed disadvantage.
What would settle it
Run the same 1024-by-1024 2D FFT on the 24-core Xeon using a mature tuned FFT library (for example FFTW with SIMD and OpenMP) and record energy with RAPL; if the energy ratio between the CPU and the n300 drops below about 3.6 or reverses, the claimed efficiency advantage is an artifact of an untuned baseline.
Extended reading notes
Core claim
On its own terms, the paper's central claim is that the Wormhole n300 with 64 Tensix cores computes a 1024-by-1024 single-precision 2D FFT in 23.56 ms at 42 W, while a 24-core Xeon Platinum Cascade Lake CPU takes 10.24 ms at 353 W, so the accelerator is about 3.6 times more energy efficient (0.99 J versus 3.62 J). The paper also claims this is the first study of an FFT on a RISC-V PCIe accelerator, and that the main performance bottleneck on Tensix is data reordering rather than compute. A series of optimizations, including chunking the domain, using the ThCon scalar unit for copies, and widening memory accesses to 128 bits, reduces a single-core FFT runtime from 14.39 ms to 5.31 ms for 16384 elements.
Load-bearing premise
The Xeon CPU baseline is a fair high-performance implementation: if the OpenMP CPU code is not using a tuned FFT library, then the measured 3.6x energy advantage of the Wormhole would be inflated.
Editorial extensions
If this is right
- If the energy-efficiency result replicates, RISC-V accelerator cards become an attractive option for power-constrained HPC systems, especially for FFT-heavy workloads.
- The optimization path identified for single-core FFTs — chunking, ThCon copies, 128-bit accesses, and one reorder per step — provides a template for other data-movement-heavy kernels on Tensix.
- Using all 120 Tensix cores on the n300 and a transpose that handles uneven row distributions would likely close much of the 2.3x performance gap with the CPU.
- For multi-dimensional FFTs, the all-to-all communication during transpose is the main scaling bottleneck; connecting multiple n300 cards with a high-performance network is the paper's stated next step to address it.
Reading between the lines
- The same data-reordering bottleneck likely affects other transforms and stencil calculations on Tensix, so the optimization techniques reported here may transfer beyond FFTs.
- If the Wormhole's energy efficiency holds at larger problem sizes, the cost per useful transform in a data-center context could favour RISC-V accelerators, especially where power is capped.
- An obvious extension is to benchmark against a production FFT library on both CPU and Wormhole to see whether the efficiency margin persists when the CPU baseline is tuned to its practical peak.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents a port of the Cooley-Tukey FFT to the Tenstorrent Wormhole n300, a RISC-V-based PCIe accelerator. On a single Tensix core, the authors explore optimizations (chunking, ThCon data copies, 128-bit accesses, and reducing data reorderings) and report a best single-core runtime of 5.31 ms for 16384 elements, versus 1.85 ms on one Xeon Platinum core. Scaling to a 1024x1024 2D FFT on 64 Tensix cores, they report a runtime of 23.56 ms with 42 W average power and 0.99 J energy, compared with 10.24 ms, 353 W, and 3.62 J on a 24-core Xeon Platinum CPU, yielding a claimed 3.6x energy-efficiency advantage. The central claim is that the Wormhole is considerably more energy-efficient despite being slower.
Significance. If the energy-efficiency result is credible, it is a noteworthy data point for RISC-V accelerators in HPC and the first published study of an FFT on the Tenstorrent architecture. The paper's breakdown of data-movement overheads (Table 2) and the optimization pathway (Table 1) are useful engineering contributions. The measurement methodology is transparent about the tools used (RAPL and TT-SMI) and runs are averaged over five executions. However, the reported comparison hinges entirely on the CPU baseline, which is not characterized as a high-performance implementation, and the abstract contradicts the table reported in Section 5. These issues must be resolved before the claimed advantage can be accepted.
major comments (4)
- [Section 3 and Table 3] The CPU baseline is not adequately characterized. The manuscript states only that 'Multi-core runs on the CPU are multi threaded using OpenMP' and that all codes are compiled with GCC at -O3. It never states whether the CPU FFT is a vendor-tuned library (e.g., FFTW, Intel MKL, or equivalent) or the authors' own radix-2 kernel sketched in Listing 1.1. If it is the latter, the 10.24 ms runtime and 3.62 J energy are not representative of a high-performance 24-core Xeon Platinum, and the claimed 3.6x energy advantage would be overstated. Please specify the exact CPU implementation, library name and version, thread pinning/affinity settings, and whether AVX-512 or other SIMD code paths were enabled. If a tuned library is not used, the comparison should be rerun against one.
- [Abstract vs. Section 5, Table 3] The abstract claims the Wormhole 'consumes around 2.8 times less energy than the CPU', but Table 3 reports 0.99 J for the n300 versus 3.62 J for the CPU, a factor of 3.66. The number 2.8 appears in Section 6 only as the single-core runtime ratio (5.31 ms / 1.85 ms). This is an internal inconsistency in the paper's primary quantitative claim, and the abstract must be corrected to match the measured 3.6x energy ratio (or the discrepancy explained).
- [Section 4 and Section 5] No numerical accuracy or correctness check is reported. The paper does not compare the FFT output against a reference implementation (e.g., FFTW or a known analytic transform) on either the CPU or the Wormhole. Without a maximum absolute or relative error measurement, it is not possible to rule out that the energy-efficient result corresponds to incorrect arithmetic, especially given that the matrix unit 'relaxes IEEE compliance' as noted in Section 2.1. Please include a validation step for at least the 1024x1024 2D FFT.
- [Section 3 and Table 3] Results are reported as averages over five runs, but no standard deviations, confidence intervals, or individual run values are given. Since the energy claim rests on a 3.6x difference and power measurements via RAPL and TT-SMI can be noisy, it is important to show that the difference is outside measurement variability. Please report the variance or, at minimum, the min and max values for the runs.
minor comments (5)
- [References] References [4] and [6] are dated September 2025 and August 2025, respectively, while the arXiv submission is dated 18 June 2025. These future dates suggest a citation error or a manuscript revision issue; please verify and correct them.
- [Listing 1.1] The loop condition 'step <= num_steps' in Listing 1.1 appears off by one; a standard radix-2 FFT on N points requires log2(N) steps, so the loop should terminate at 'step < num_steps'.
- [Section 3] The paper reports Tenstorrent runs on a host with a 26-core Skylake Xeon Platinum 8170, while the CPU comparison uses a 24-core Cascade Lake Xeon Platinum 8260M. The reason for using a different CPU for the comparison is not explained; if the host CPU was available, it would be more natural to compare against it.
- [Table 2] The last two rows of Table 2 both report 0.9 ms, but the paper does not comment on why disabling the external write path (and write reordering) has no effect when read reordering is also disabled. A brief explanation would improve interpretability.
- [Section 4] The paper states that compute-only performance was comparable for the SFPU and FPU, but no supporting data or table is provided for this claim. Adding a short comparison would be useful.
Circularity Check
No circularity: the FFT port and energy comparison are measured results with no fitted parameters or self-citation chain.
full rationale
The paper's claims are empirical measurements of a ported Cooley-Tukey FFT on Tenstorrent hardware compared against a CPU. Section 4 describes implementation optimizations; Section 5 Table 3 reports measured runtime, average power, and energy (10.24 ms/353 W/3.62 J CPU vs 23.56 ms/42 W/0.99 J n300), and the 3.6x energy-efficiency figure is the direct ratio 3.62/0.99. There is no fitted parameter later renamed as a prediction, no equation in which an output is defined in terms of the target quantity, and no uniqueness theorem or ansatz imported from the authors' prior work. The only self-citation, [1], describes prior stencil work and is contextual background, not load-bearing for the FFT results. The uncharacterized CPU baseline (Section 3 states only that CPU runs are 'multi threaded using OpenMP', without naming FFTW/MKL) is a fairness/validity concern about whether the CPU comparison is a strong baseline, and the abstract's 'around 2.8 times less energy' is inconsistent with Table 3's 3.6x, but these are correctness risks, not circularity. No circular step can be exhibited, so the circularity score is 0.
Assumptions & free parameters
assumptions (3)
- domain assumption The CPU OpenMP FFT implementation is a fair, high-performance baseline.
- domain assumption RAPL (CPU package) and TT-SMI (card) power measurements cover comparable system components.
- domain assumption The tt-nn transpose routine is correct and does not dominate the n300 runtime in a way that invalidates the comparison.
Cite this review
Pith. "Pith review of Exploring Fast Fourier Transforms on the Tenstorrent Wormhole." pith.science (2026). https://pith.science/paper/IOXN33RI
@misc{pith2026250615437,
author = {Pith},
title = {Pith review of: Exploring Fast Fourier Transforms on the Tenstorrent Wormhole},
year = {2026},
howpublished = {\url{https://pith.science/paper/IOXN33RI}},
note = {Machine review of arXiv:2506.15437}
}
read the original abstract
Whilst numerous areas of computing have adopted the RISC-V Instruction Set Architecture (ISA) wholesale in recent years, it is yet to become widespread in HPC. RISC-V accelerators offer a compelling option where the HPC community can benefit from the specialisation offered by the open nature of the standard but without the extensive ecosystem changes required when adopting RISC-V CPUs. In this paper we explore porting the Cooley-Tukey Fast Fourier Transform (FFT) algorithm to the Tenstorrent Wormhole PCIe RISC-V based accelerator. Built upon Tenstorrent's Tensix architecture, this technology decouples the movement of data from compute, potentially offering increased control to the programmer. Exploring different optimisation techniques to address the bottlenecks inherent in data movement, we demonstrate that for a 2D FFT whilst the Wormhole n300 is slower than a server-grade 24-core Xeon Platinum CPU, the Wormhole draws around 8 times less power and consumes around 2.8 times less energy than the CPU when computing the Fourier transform.
Figures
Figures from the paper (3 more)
Reference graph
Works this paper leans on
-
[1]
Brown, N., Barton, R.: Accelerating stencils on the tenstorrent grayskull risc-v accelerator. In: SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis. pp. 1690--1700. IEEE (2024)
work page 2024
-
[2]
In: International Conference on High Performance Computing
Brown, N., Jamieson, M.: Performance characterisation of the 64-core sg2042 risc-v cpu for hpc. In: International Conference on High Performance Computing. pp. 354--367. Springer (2025)
work page 2025
-
[3]
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: Proceedings of the SC'23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis. pp. 1566--1574 (2023)
work page 2023
-
[4]
Cawley, P.: Tenstorrent Wormhole Series (September 2025), https://www.corsix.org/
work page 2025
-
[5]
Strang, G.: Linear algebra and its applications (2000)
work page 2000
-
[6]
Tenstorrent: Wormhole Tensix Processor (August 2025), https://cdn.sanity.io/files/jpb4ed5r/production/6217a901d675d37ccb3cf1e8ba74f91a9f992577.pdf
work page 2025
-
[7]
, " * write output.state after.block = add.period write
ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...
-
[8]
write newline
" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize ":" * " " *...
Reviewed August 6, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.