celt+silk: migrate hot kernels to Go simd/archsimd (vanilla wins + silk widen + gated complex IMDCT/MDCT)

[thesyncim]

Summary

Migrates the hot CELT float kernels from hand-written Plan9 assembly to Go's
experimental simd/archsimd package (Go tip, GOEXPERIMENT=simd) and answers the
question: is portable Go SIMD close enough to delete the hand assembly? Short
answer: yes for the float kernels — Go SIMD matches or beats the asm on both Apple
Silicon and Graviton and at the codec level, once per-access bounds checks are
removed. Everything is gated goexperiment.simd; asm and purego paths are untouched
for normal builds. No kernel migrated without bit-exact parity + benchmarks.

WIP — do not merge yet. This is the single PR for the whole migration: the
CELT float wins, the silk widen/narrow coverage, and the complex IMDCT/MDCT
kernels (gated behind gopus_reverse64 — see below). Iterating over the next
several days.

Ported (bit-exact): scale_into, stereo_merge, inner_prod,
prefilter_dual_inner_prod (both arches); xcorr, l1_abs_sum, comb_const,
exp_rotation (arm64, where the hand asm lived). comb_const runs at asm
parity; exp_rotation ties and is ~12% faster on the stride-2 case.

Also ported (silk, arm64) as measurement-track coverage, slower than the asm
because archsimd lacks the native widen/narrow fusion: int16_float32 (+20.8%,
HiToLo emulates the missing ExtendHi4=SXTL2) and float_to_int16 (+35.2%,
Round+ConvertToInt32+SaturateToInt16 vs the asm's fused FCVTNS+SQXTN2).
These are honest negative data points — archsimd can be bit-exact here but not
yet competitive.

Finding 1 — bounds-check elimination is the whole game

The kernels first used archsimd.LoadFloat32x4(s[i:]), which emits a slice bounds
check + panic path on every load/store. A subagent sweep proved that machinery — not
the SIMD — made archsimd 3-5× slower than the asm. Loading through raw advancing
pointers (unsafe.SliceData + unsafe.Add + LoadFloat32x4Array, via shared
loadF32x4/storeF32x4/loadF32x8/storeF32x8 helpers) removes it.

Finding 2 — kernel gap, archsimd vs hand asm (benchstat)

kernel	bottleneck	M4 Max	Graviton (Neoverse)
inner_prod	compute	−11%	−20% ✅
l1_abs_sum	compute	−57%	wins ✅
xcorr / prefilter_dual	compute	~tie	~tie ✅
stereo_merge	mixed	beats/ties	+1% ✅
scale_into	pure memory	−28%	+19% ⚠️

archsimd wins on compute-bound, ties on mixed, and trails only on the pure
memory-copy scale_into on Neoverse (+19%, down from +280% before the fix). On M4 Max
it beats the asm across the board. amd64 (no prior asm) gets a clean 2-7× over scalar.

Finding 3 — the 4-way comparison (codec scoreboard vs libopus 1.6.1 C)

CELT encode, gopus/libopus C ratio (lower = closer to C), via
benchmark_libopus_scoreboard_test.go under three Go builds + self-timed libopus C:

CELT config	pure Go	Go asm	Go SIMD	libopus C
mono 8k 20ms	1.33×	1.08×	1.04×	1.0
mono 24k 10ms	1.78×	1.51×	1.38×	1.0
mono 48k 20ms	1.46×	1.16×	1.13×	1.0
stereo 48k 20ms	1.50×	1.35×	1.27×	1.0

Go SIMD matches or edges the hand asm at the codec level and is the closest Go
build to libopus C; both Go-SIMD and Go-asm are far ahead of pure Go. SILK is
unaffected (no SILK kernels migrated). (Single-run 20x; archsimd-vs-asm is ~a wash
within noise on some configs.)

Complex IMDCT/MDCT kernels — gated behind gopus_reverse64

The 7 complex kernels — imdct_pre_kiss, imdct_tdac, imdct_post_kiss,
mdct_post_twiddle, mdct_mid_fold, mdct_fold1, mdct_fold3 — were the last CELT
float kernels blocked on a missing op: a full 4-lane lane-reverse. They deinterleave
the kissCpx re/im streams with ConcatEven/Odd, reverse descending streams with a
reverse4 built from Float32x4.Reverse64 (NEON VREV64), and scatter the
bit-reversed fold output via temps + a scalar loop (as the asm does).

Reverse64 is not in upstream Go yet — submitted as golang/go#80032. So the
complex archsimd path is gated behind the gopus_reverse64 build tag:

• stock-gotip CI is green: without the tag the experiment build uses the complex
  asm fallback (!goexperiment.simd || !gopus_reverse64), and CI validates the
  vanilla archsimd + the complex asm;
• the complex archsimd path builds only with GOEXPERIMENT=simd -tags gopus_reverse64
  on the patched toolchain (thesyncim/go), until #80032 lands and the gate is dropped;
• the default build is unchanged — the hand asm still runs.

What we win: archsimd hits parity on the complex family (not the regression you'd
expect from emulated VLD2) — imdct_post 37.6↔37.6 ns, imdct_tdac beats asm
−15%, the folds bit-exact + full-suite green; imdct_pre is the lone +26% outlier
(the VLD2-deinterleave gap). With these, every CELT float kernel is portable.

Verdict on deleting the asm

For the migrated CELT float kernels, the hand asm is replaceable by portable Go
archsimd with equal-or-better performance on both arches and at the codec level —
scale_into (pure copy-scale) is the lone marginal case (+19% on Neoverse). The asm
stays the default here (archsimd is gotip-only); flipping the default is a follow-up
once simd/archsimd ships in a Go release.

Not migrated (genuinely blocked — needs an op archsimd lacks)

(The complex twiddle/fold kernels that needed a lane-reverse are now ported above,
behind gopus_reverse64.)

• kf_bfly / kf_bfly4m1 — strided twiddle gather + cross-lane radix recombine
• haar1 — strided gather + even/odd deinterleave archsimd lacks for floats
• silk resample_fir — indexed-lane FMLA plus int16↔int32 widening (int16_float32
  and float_to_int16 are now ported above, at a measured widen/narrow-fusion gap)
• silk pitch_xcorr — indexed-lane FMLA (fmla v0.4s, v5.4s, v4.s[i]) has no
  archsimd form; emulating it per lane regresses, and its output mixes fused
  (vector lags) and non-fused (scalar-tail lags) accumulation
• deemphasis, lpc_synth, up2hq_core — serial IIR, not vectorizable
• cwrs, pvq_search — integer combinatorial

Harness

scripts/bench-simd-kernel.sh <pkg> <bench> benchstats default-build (asm) vs
archsimd. The non-blocking test-simd-experiment CI job runs it on a 2-arch matrix
(ubuntu-latest amd64 + ubuntu-24.04-arm Graviton).

Test plan

• Builds clean under GOEXPERIMENT=simd gotip and the normal toolchain (9 configs)
• Bit-exact parity on every runnable config; AVX/FMA + Graviton via CI
• asm + purego intact; gofmt + vet clean; unsafe pointer walks stay in range
• Kernel benchmarks (M4 Max + Graviton) + 4-way codec scoreboard vs libopus C

[thesyncim]

4-way comparison — Decode half (CELT decode, gopus/libopus-C ratio, lower = closer to C)

Complements the Encode table in the PR description. Decode is where scale_into and
stereo_merge live, and archsimd is consistently the closest Go build to libopus C:

CELT decode	pure Go	Go asm	Go SIMD	libopus C
mono 8k 10ms	1.60×	1.50×	1.29×	1.0
mono 48k 10ms	1.70×	1.64×	1.23×	1.0
mono 48k 20ms	1.57×	1.45×	1.32×	1.0
stereo 24k 10ms	1.52×	1.47×	1.31×	1.0
stereo 48k 10ms	1.48×	1.47×	1.34×	1.0

Go SIMD wins on most decode configs (a couple noisy ties at 20x). Final CI green.

[thesyncim]

Evaluated: the portable scalable simd package (vs fixed-width archsimd)

Tried reimplementing scale_into on the scalable simd.Float32s type (auto-widens to
the platform width — 4 on this arm64, 8/16 on AVX2/AVX-512 — from one source, the more
portable alternative to per-arch Float32x4/Float32x8).

Two blockers at this Go tip:

1. It crashes the compiler on arm64 — internal compiler error: nil pointer dereference in cmd/compile/internal/midway/rewrite.go (the pass that lowers
   scalable vectors). Not usable yet.
2. Even if it compiled, its API is slice-only (LoadFloat32s([]float32)) with no
   raw-pointer load, so it would keep the per-access bounds check that the unsafe
   archsimd kernels eliminate — the very cost that decides asm-vs-archsimd here.

Conclusion: fixed-width archsimd + the unsafe raw-pointer trick is the viable
path; the scalable package is too immature on arm64 to evaluate for performance.
Revisit once the midway backend stabilizes and an array-pointer load lands.

[thesyncim]

scale_into Graviton holdout — closed via 16-wide unroll

scale_into was the lone kernel trailing the hand asm on Neoverse (+19% at N480).
Widening the arm64 unroll from 8 to 16 elements/iter (amortizing loop control on the
overhead-bound core) closes it — Graviton archsimd vs asm:

N	8-wide (before)	16-wide (now)
64	(trailed)	−11% (archsimd faster)
176	—	+4.6%
480	+19%	+8.6%

All sizes now ≤8.6% or faster — inside the 10-15% replace-the-asm bar. M4 Max also
improved (N480 −20% vs asm, was −17%); still bit-exact.

Updated verdict: with the holdout closed, archsimd is within-or-better than the
hand NEON asm on all 6 migrated kernels across both M4 Max and Graviton — the
float-kernel assembly is fully replaceable by portable Go SIMD (once simd/archsimd
ships in a Go release; asm stays the default until then).

[thesyncim]

Re-examined the "blocked" kernels — root cause is archsimd's thinner arm64 backend

Pushed harder on whether more kernels can replace the asm. Findings:

• silk int16↔float32 is portable, not blocked (I was wrong): Int16x8.ExtendLo4ToInt32()
  → Int32x4.ConvertToFloat32() → ×2⁻¹⁵ is bit-exact. But benchmarked it's +27% vs the asm
  (tried 4-lane and 2-load 8-lane, both ~+27%) — arm64 archsimd has ExtendLo4 but no
  ExtendHi4, so it can't widen both int16 halves like the asm's SXTL/SXTL2. Portable but
  not a competitive replacement → reverted (won't ship a regression).
• FFT/MDCT complex kernels are genuinely arm64-blocked: the bit-reinterpret-back
  (Int32x4.AsFloat32x4) exists on amd64 but not arm64, so the re/im float deinterleave they
  need is impossible without a memory round-trip.

Root cause: archsimd's arm64 backend is less complete than amd64 (doc: "currently supports
AMD64"). Missing on arm64 — ExtendHi4, AsFloat32x4 reinterpret, float deinterleave/reverse,
gather — is what caps competitive replacement beyond the 6 float kernels. Those 6 remain the set
archsimd matches/beats on arm64; more will qualify as the arm64 backend gains ops.