boxsum summed its ring background in double and compared each ring pixel
against a double threshold. The pixels are integers: a sum of at most a
thousand int32 values is exact in a 64-bit integer AND exact in a double, so
the two agree bit for bit, and comparing an integer against the floor of the
threshold accepts exactly the same pixels as comparing it against the threshold
itself. Both loops now do integer arithmetic.
That was 39% of the card's double-precision pipe on the development machine and
about three quarters of it on the production one, where the double rate is
unchanged from Turing while the single rate has doubled - so this is worth more
there than here.
Alongside it, three things in the combine kernel. rr_nusable was computed by a
whole extra walk over every observation and then never downloaded or read by
anything. sum_wb and sum_cwb have no F in them, so they are the same in all
three reweights and only the last round's values are ever used - two thirds of
them were two divisions each, discarded. And CombineParams was the one
parameter struct in the file without __restrict__, so the compiler could not
assume the observation arrays and the freshly allocated fulls arrays were
distinct.
Measured on a crystal with 66 million partial observations: boxsum 12.2 s ->
8.3 s, the combine kernel 8.0 s -> 7.6 s, whole crystal 1m17s -> 1m12s. Battery
15m32s -> 9m59s. Same space group on all 24 crystals, none failed.
Two things measured and NOT kept, recorded so they are not tried again: sorting
the raw-hkl runs by length so a warp holds runs of similar length - it trades
away the locality of neighbouring runs in the permutation and came out slower
(7.6 s -> 8.8 s); and page-locking the integrator's host staging arrays
individually - eleven separate registrations of small heap allocations overlap
on shared pages and the driver refuses them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
