T

jungfrauandClaude Opus 5 eb634400ea Read four pixels at a time in the ring reduction

reduce_rings_shared was 69% of all GPU kernel time - 116.8 s of a 70 s run
across four cards. It is not bandwidth bound: flag_strong streams the same two
arrays through the same grid-stride loop and reaches 196 GB/s, while this
reached 30. The difference is the shared-memory atomics. Lanes in a warp read
consecutive pixels along a detector row, a ring is a few pixels wide, so most of
a warp lands in a handful of rings and the atomics to each one serialise.

Two changes.

The block reads four pixels per thread as one 16-byte and one 8-byte
transaction, and merges the ones that fall in the same ring in registers before
touching shared memory. Consecutive pixels usually DO share a ring, so this is
where the win is: a run costs one set of atomics instead of one per pixel.
npix is not guaranteed to be a multiple of four - it is width x height on the
converted path, and detectors are not obliged to be even - so the vector loop
stops short and a scalar loop finishes the remainder. Reading past the end would
not fault, which is worse than if it did: it would fold uninitialised device
memory into the accumulators and move the detection threshold in a way that does
not reproduce.

And the grid is sized from the occupancy the device reports, per pass. The two
passes have different shared footprints - the first carries the corrected rings
as well - so they do not fit the same number of blocks, and a grid sized for one
left the other running a second wave at a quarter occupancy. The comment that
justified the old grid reasoned from 1536 threads per SM, which is an Ada
number; the card it ran on holds 1024.

The run totals are still exactly what they were. The accumulators are unsigned
64-bit, so summing a run in a register and adding it once is the same value as
adding each pixel separately - addition mod 2^64 is associative, overflow
included - which is what keeps the ring statistics, and therefore the detection
threshold, independent of how the work was grouped. That is the property the
integer accumulators exist for. (The run accumulators are unsigned for the same
reason: signed overflow would be undefined, and four squares of a large pixel
value reach 2^64.) The corrected float sums, which feed the reported profile
rather than any decision, change in their last bits as they already did between
runs.

Measured on a 16M-pixel rotation dataset: the kernel 116.8 s -> 19.1 s (6.1x),
no longer the largest; the whole run 70 s -> 39.5 s. Full 24-crystal battery:
same space group on all 24, none failed, 15m32s -> 12m47s.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-15 19:21:24 -04:00