Reuse Stockham twiddles in large batched Bluestein FFTs - #4084
Open
PhysicistJohn wants to merge 1 commit into
Open
Reuse Stockham twiddles in large batched Bluestein FFTs#4084PhysicistJohn wants to merge 1 commit into
PhysicistJohn wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fused Bluestein runs two Stockham transforms with the same stage roots for every
transform in the batch. For complex64 transforms using the exact 4096-point
internal plan with total batch at least 1024, this change generates one
584-value radix-twiddle table on the host, appends it to the existing Bluestein
constants allocation, and reuses it in both internal FFTs. Dynamic and
precomputed roots use the same shared radix codelets.
On an Apple M5 Max, matched public
fftandifftcalls improve by 3–4% atbatch 1024 and by up to 7% at batch 2048. The selected path adds 16,384 bytes
of measured peak allocation and 34,288 bytes (0.0206%) to
mlx.metallib, withno symbol-name changes.
Smaller batches, other internal plans, and real transforms retain dynamic
twiddles. No public API, buffer binding, or kernel entry point changes.
Results
Public lengths 1030, 1031, 1531, and 2047 all select the 4096-point internal
plan. All 20 selected timing cases improved with paired 95% lower bounds above
1.0.
fftifftfftfftifftfftcontrolThe other controls were neutral: the smaller 1024-point Bluestein plan
measured 1.0009x in both directions, and
rfft(1031)measured 0.9991x. Theirpaired intervals included 1.0 and peak allocation was unchanged.
Validation
under Metal API validation.
reachable fast
sin/coscalls from both internal passes and usespacked-table loads.
batch-one dynamic-twiddle result. All recorded cases were finite and passed
the existing tolerances; worst normalized RMSE was
5.443e-7and worstabsolute error was
6.574e-4.Methodology and artifact accounting
Measurements compare
mainat8d666298with candidateb5cd45e4usingstatic Metal on macOS. Each case used deterministic matched inputs, 10
warmups, 9 samples of 30 transforms, 5 alternating ABBA/BAAB rounds, and 10
paired comparisons. Timings include operation construction, host constant
generation, dispatch, evaluation, and synchronization.
mainmlx.metalliblibmlx.dylibThe Metal symbol-name sets are identical.