calculate_fft_result (the per-direction prominence peak search) was 61-65% of the GPU kernel time of
a de-novo stills run, and the card is what limits that loop. It is one dependent chain per direction,
latency-bound. Two exact changes, taken where the spectrum holds a whole background window (any
FFT max cell above ~30 A; the general loop stays for the rest):
- the sliding window written out as its three phases (clamped at the start, centred, clamped at the
end): the same additions and subtractions in the same order, so the running double sum is bit for
bit the same, but the loads no longer sit behind data-dependent while loops and are issued ahead;
- the window mean divides by a constant width, so the double division (a long FP64 iteration on a
consumer card) is replaced by the reciprocal multiply plus one correction by the exact remainder,
which returns the correctly rounded quotient (Markstein). Checked on the CPU against the division
for 4e8 random dividends over all odd widths 3-401: 0 differences.
Measured (RTX 5080, box loaded by other builds, load 12-25): kernel minimum 1.50 -> 0.83 ms, mean
under the 8-stream pool 4.7 -> 2.8 ms; de-novo stills 2000 frames ABAB 113/120 -> 127/138 frames/s.
p.hkl byte-identical (2000 and 3000 frames, base and new min-pix schemes).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
leonarski_fandClaude Opus 5.5
ab645847ed
