Pith. sign in

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 →

arxiv 2506.15437 v1 pith:IOXN33RI submitted 2025-06-18 cs.DC

classification cs.DC
keywords FastFourierTransformCooley-TukeyalgorithmRISC-VacceleratorTenstorrentWormholeTensixarchitecturedatamovementoptimizationenergyefficiency2DFFT
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

The paper ports the Cooley-Tukey Fast Fourier Transform to the Tenstorrent Wormhole, a PCIe RISC-V accelerator built around Tensix cores, and measures how it compares with a server CPU. For a 1024-by-1024 2D FFT, 64 Tensix cores run slower than a 24-core Xeon Platinum CPU but draw about eight times less power, consuming roughly 3.6 times less energy overall. The key obstacle is data reordering between FFT steps, not the arithmetic, and the paper shows that chunked processing, scalar-unit copies, and 128-bit memory accesses each cut runtime. If the result holds, RISC-V accelerators offer a low-power route to HPC mathematics without replacing the host ecosystem.

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.

Watch

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

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

  • 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.
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.

Referee Report

4 major / 5 minor

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)
  1. [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.
  2. [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).
  3. [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.
  4. [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)
  1. [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.
  2. [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'.
  3. [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.
  4. [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.
  5. [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

0 steps flagged · score 0.0 of 10

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 0 free parameters · 3 assumptions · 0 invented entities

No fitted parameters or new physical entities are introduced. The central claim depends on measurement comparability: a representative CPU baseline, consistent power instrumentation, and a correct transpose routine.

assumptions (3)
  • domain assumption The CPU OpenMP FFT implementation is a fair, high-performance baseline.
    Section 3 and Table 3. The paper gives no details of the CPU FFT kernel and does not mention FFTW or MKL, so the comparison rests on this unstated assumption.
  • domain assumption RAPL (CPU package) and TT-SMI (card) power measurements cover comparable system components.
    Section 3. If RAPL excludes DRAM or TT-SMI excludes host power, the energy ratio could be distorted.
  • domain assumption The tt-nn transpose routine is correct and does not dominate the n300 runtime in a way that invalidates the comparison.
    Section 5, where the paper says it 'leveraged the transpose routine from Tenstorrent's tt-nn library'. Numerical correctness of the 2D FFT result is not independently verified.

how reviews work

0 comments
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 reproduced from arXiv: 2506.15437 by the authors.

Figure 1
Figure 1. A single Tensix core in the Wormhole accelerator, containing five RISC-V baby cores, 1.3MB of local SRAM memory, a compute engine and two routers to the Network on Chip (NoC). The dst register is used as both an input to, and output from, the vector unit and this is why it is split into 16 segments. Consequently, compute can undertaken by the matrix unit and results can then be provided to the vector unit for furthe… view at source ↗
Figure 2
Figure 2. illustrates an FFT operating on eight input values, requiring three steps. We follow a 2-radix approach, were in the first step calculations involving neighbouring values are undertaken, in the second step intermediate results are then calculated between neighbour plus (or minus) 2, and in the third step intermediates with neighbour plus (or minus) four [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Basic design approach of running FFTs on a Tensix core [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Two data reordering stages per step, converting back to the original data order between steps To this point, as per [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: One data reordering stage per step, converting to the next step’s data order directly to reduce the overall number of expensive data reorderings required. Performance of the one-copy optimisation is reported as Single data copy in [PITH_FULL_IMAGE:figures/full_fig_p01…
Figure 6
Figure 6. Figure 6: Illustration of data movement involved in a 2D FFT We enhanced our FFT implementation to work across a several locally held rows and leveraged the transpose routine from Tenstorrent’s tt-nn library to undertake transposition across the Tensix cores. For simplicity we a…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

8 extracted references · 6 canonical work pages

  1. [1]

    In: SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis

    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)

  2. [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)

  3. [3]

    In: Proceedings of the SC'23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis

    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)

  4. [4]

    Cawley, P.: Tenstorrent Wormhole Series (September 2025), https://www.corsix.org/

  5. [5]

    Strang, G.: Linear algebra and its applications (2000)

  6. [6]

    Tenstorrent: Wormhole Tensix Processor (August 2025), https://cdn.sanity.io/files/jpb4ed5r/production/6217a901d675d37ccb3cf1e8ba74f91a9f992577.pdf

  7. [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. [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 ":" * " " *...

Pith tools

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