fix(deps): update module github.com/go-fft/fft to v0.27.1

[tannevaled]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/go-fft/fft	v0.23.0 → v0.27.1

---

Release Notes

go-fft/fft (github.com/go-fft/fft)

v0.27.1

Compare Source

Documentation only: performance claims at v0.27.0, recomputed from the raw parity runs (benchmarks/results/current-numbers-v0.27.0/). Within 5% of FFTW or faster: Neoverse-N1 24/24 (all faster), Zen 3 18/24 (17 faster), Cascade Lake 15/24 (14 faster, every 2-D row). README, BENCHMARKS.md and the docs now carry a note on v0.26.3's correctness fix (wrong N-D results on Intel AVX-512 for axes of length 9·p in v0.25.0–v0.26.2). Round 39 disproved "2-D 512² is allocation placement"; the sentence is gone. #​75

v0.27.0

Compare Source

Round 39, Cascade Lake (Intel AVX-512): every 2-D parity row now faster than FFTW.

• Wider column strips (cl3StripWidth): an N-D axis spanning ≥ 2^18 elements with lines ≥ 256 apart takes 128 lines (n ≤ 256) or 64: the strip step 1.93–2.36× faster at 512², 1.26× at 1024², up to 2.97× on 3-D axes.
• 2-D rows on the stack-frame kernels on Intel too (cl3FrameRows): 32² 1.29×, 64² 1.14×, 128² 1.06×.
• Round 35's "2-D 512² is allocation placement" did not hold: placement moved it < 10% in one process; the column passes wait on lines the prefetchers do not fetch.
  End to end vs v0.26.1 (9 rounds, 4 placements): 2-D 512² 1.219×, 1024² 1.183×, 32² 1.308×, 64² 1.129×; untouched rows 0.99–1.02. FFTW parity: 2-D 64²/128²/256²/512²/1024² 0.937/0.946/0.949/0.883/0.834 (were 1.061/0.981/0.998/1.003/1.025); rows faster than FFTW 10 → 14 of 24. Bit-identical outputs (wide vs narrow strips); keeps v0.26.3's N-D guard. Details: BENCHMARKS.md, Round 39.

v0.26.4

Compare Source

Measurements only (no code change): Round 38 — a radix-32 pass on amd64 was built bit-identical and lost to split radix 8 everywhere it was timed (Zen 3: complex 1024 0.85×, 256 0.81×), so it is not shipped (code on branch perf-r32x-r38). Zen 3's RFFT rows against FFTW after v0.25.0's tail jump moved within the run-to-run spread. #​74

v0.26.3: — fixes wrong N-D results on Intel AVX-512

Compare Source

Correctness fix. Upgrade if you run N-D transforms on Intel CPUs with AVX-512.

Affected: v0.25.0, v0.26.0, v0.26.1, v0.26.2, on Intel CPUs with AVX-512 (e.g. Cascade Lake, Ice Lake, Sapphire Rapids) only.

Symptom: FFTN / FFT2 / PlanN (and their inverses) returned wrong values, silently, when an axis other than the last has a length 9·p with p a prime that no Stockham pass handles — 153, 171, 207, 261, 342, … (120 of the lengths up to 2000). 1-D transforms, real transforms, the last axis, and every other CPU (AMD, Intel without AVX-512, arm64, and the other architectures) were correct.

Cause: v0.25.0's radix-9 route made compTakes16(9·p) true while the axis plan of 9·p is Rader or Bluestein; the N-D plan replaced it with a Stockham plan whose passes multiply to 9, not 9·p.

Fix (#​73): the strip axis takes the no-radix-16 Stockham plan only when its passes multiply to n, and that plan's constructor now refuses (panics with an internal message) a partial factorization instead of transforming the wrong length. New tests check every strip-axis length 2–2000 and force the radix-9 route on any amd64 CPU, so CI catches this whatever runner it gets.

How it was found: FuzzPublicAPI failed once on a CI runner with AVX-512 (shape [171 22]: FFTN round trip) and passed on rerun on another runner; reproduced deterministically on Cascade Lake.

v0.26.2

Compare Source

Measurements only (no code change): Round 40, Neoverse-N1 parity re-measured at v0.26.1. Faster than FFTW on all 24 rows (unchanged); complex 10007 (Bluestein) 0.72 → 0.689 × FFTW. A/B v0.25.0 vs v0.26.1 (one external harness, 4 heap placements, 9 rotated rounds): CMulTo costs nothing on arm64 — complex 10007 0.980× the time, every round below 1. #​70

v0.26.1

Compare Source

Documentation only: every performance claim brought to v0.26.0, recomputed from the raw parity runs (benchmarks/results/current-numbers-v0.26.0/).

• Within 5% of FFTW or faster: Neoverse-N1 24/24 (faster on all 24), Zen 3 18/24 (faster on 17), Cascade Lake 15/24 (faster on 10). Faster than numpy.fft and scipy.fft on 24/24 on every host, than gonum on 19/19.
• The rows within 5% but still slower than FFTW are named; the stale "where FFTW still leads" lists are gone.
• Corrected: v0.25.0's untangle tail jump and v0.26.0's CMulTo do run outside their vendor's path (Zen 3/Haswell RFFT; arm64 Bluestein) and were not re-measured against FFTW there; the parity method pins one core (the docs said all hardware threads).

v0.26.0

Compare Source

Round 36, Zen 3 (AMD AVX2). Every change runs only where kernels.IntelCPU is false.

• Bluestein's pointwise products on AVX2 (zmCMulAVX2, go-asmgen, bit-identical on amd64): the three products 48.5 → 22.8 µs; complex 10007 1.072 → 0.821 × FFTW.
• 2-D rows on the stack-frame kernels: a 64-point row 100 → 73 ns; 2-D 64² 1.031 → 0.894 × FFTW.
• e = 11, 12 composites up to 32768 end with radix-4 tails instead of a radix-8 pass whose eight streams shared one L1 set (6144: that pass 4.6 → 2.0 µs).
• Radix-3 and radix-5 passes in the split layout (32 generated kernels) for 46 composites confirmed by a sweep and two 15-round A/Bs (1.02–1.62×, median 1.07×).
  FFTW parity on Zen 3 (within 5% or faster) 16 → 18 of 24, faster on 13 → 17. Re-checked against v0.25.0 between binaries: complex 10007 1.27×, 2-D 64² 1.17×, complex 1000 1.12×, 6144/10240 1.12–1.13×; every composite ≤ 16384 1.07× geometric mean. Accuracy: numpy on the exact exported bytes ≤ 1.3e-15. Details: BENCHMARKS.md, Round 36.

v0.25.0

Compare Source

Round 35, Cascade Lake (Intel AVX-512).

• Blocked schedule for large powers of two opens with radix-8 passes (65536 → 8·8·4·4·8·8, 2^20 → 8·8·8·8·8·4·8): complex 65536 1.076×, 2^20 1.087×.
• Radix-9 AVX2 kernels (go-asmgen, bit-identical to a new Go pass9): on AVX-512 Intel, leading radix-3 pairs merge into radix 9 (1296 → 9·12·12, FFTW's own plan): 44 composites ≤ 16384 1.149× geometric mean (1.065–1.329).
• The stack-frame kernels (Round 32) now run on Cascade Lake too, including the 512-bit passes: complex 64/128/256/512 1.36/1.18/1.215/1.08×, RFFT 256–1024 1.07–1.13×.
• 512-bit untangle extended to m = 65536 (forward): RFFT 65536 1.058×.
• Round 37's tail-jump for the 512-bit untangle wrapper folded in (no call when no pair is left).
  FFTW parity on Cascade Lake (within 5% or faster) 13 → 15 of 24; complex 256 1.28 → 1.04, RFFT 256 1.10 → 0.97. Rules gated to Intel with AVX-512. Accuracy unchanged (numpy on the exact exported bytes ≤ 6.2e-16). Details: BENCHMARKS.md, Round 35.

v0.24.0

Compare Source

Round 37, Haswell and Neoverse-N1.

• Neoverse-N1: the NEON untangle/retangle kernels use VLD1/VST1 + VZIP instead of VLD2/VST2 and lane swaps, and read a pre-split twiddle table (bit-identical): untangle 1.19–1.21×, retangle 1.17–1.19× in-process; RFFT 256 and 1080 0.953 / 0.962 of v0.23.1's time. N1 is now faster than FFTW on all 24 parity rows (RFFT 256 1.049 → 0.991, RFFT 1080 1.039 → 0.995).
• Haswell: the contiguous axis of N-D plans of at least 2^16 elements takes 1024 = 4·8·4·8 (an even pass count saves the in-place copy of 8·8·16): 2-D 64×1024 … 1024² 1.04–1.06× faster.
• Haswell: 6144 → 3·8·16·16 and 10240 → 5·8·16·16, 1.20× faster.
• Measured, not fixed: Round 31's unconditional 512-bit untangle call costs ~1.5% on RFFT/IRFFT 256 on CPUs without AVX-512 (Haswell); being addressed on Cascade Lake.
  Accuracy: numpy on the exact exported bytes ≤ 7.2e-16. Details: BENCHMARKS.md, Round 37.

v0.23.2

Compare Source

CI and tests only; no library change.

• CI pins Go 1.27.2 (#​64).
• The Round 32 frame-kernel tests failed whenever a GitHub runner was an Intel CPU with AVX-512: they asserted that small plans take the AVX2 frame kernels, which only the AVX2 route builds. They now force that route (znAVX2Route flips the kernel switches and the tables computed at init, then restores them) instead of depending on the runner's CPU; nothing is skipped on Intel. Checked on Cascade Lake: main's test binary fails both tests as CI did; with the fix both suites pass at 100% coverage. (#​65)

v0.23.1

Compare Source

Documentation only: every performance claim brought to v0.23.0.

• Current numbers recomputed from the raw runs by one tool (benchmarks/results/current-numbers-v0.23.0/partab.go.txt): within 5% of FFTW or faster on 24/24 rows on Neoverse-N1 (faster on 22), 15/24 on Zen 3 (11) and 11/24 on Cascade Lake (10); faster than numpy.fft and scipy.fft on 24/24 everywhere, than gonum on 19/19. The rows within 5% but still slower than FFTW are named.
• Round 34: Zen 3 re-measured cleanly at v0.23.0 (Round 32's parity runs ran under load 3.3–4.2).
• False sentences removed ("no later release changes the float64 path", the v0.19.0 2-D 1024² regression, now fixed in v0.22.0); Round 32's 2-D ratios, taken against the wrong column, corrected.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.