jungfrauandClaude Opus 5 057fff98b2 Give each FFT direction a block and its histogram shared memory
The de-novo indexer projects every spot onto each of 16384 search directions and
bins the projections; the peak of each direction's spectrum is a reciprocal
lattice row spacing. One thread owned a whole direction, so neighbouring lanes
wrote 12.6 kB apart and every warp instruction touched 32 separate sectors of a
206 MB buffer with no chance of staying in a 4 MB L2. 160 million scattered
global read-modify-writes, at about 14% of the card's bandwidth.

One block per direction now, with the bins in shared memory. They are counts, so
they are held as integers: an integer atomicAdd is a real shared-memory
instruction where the float one compiles to a compare-and-swap retry loop, and a
count below 2^24 converts to float exactly, so the output is bit for bit what the
repeated += 1.0 produced. Above 48 kB of bins the old kernel still runs.

245.75 ms per launch -> 4.08 ms, so 0.98 s of the run -> 0.016 s. This machine
runs two of them at once on two cards, so it is worth about half a second here
and about a second on the single-GPU machines the viewer and the broker run on.
The FFT it feeds takes 3.3 ms; preparing its input took 70x longer than
transforming it.

Alongside it, the per-frame scale fit divided by k^2 once per observation per
IRLS iteration, and a loop-invariant divisor does not get hoisted out of a double
division - ptxas emits the whole Newton refinement of the reciprocal every time.
Hoisted, as 1/sigma already is a few lines above; the same expression in the
three CPU scale paths went with it so the two stay algebraically identical.
54.92 ms per launch -> 44.56 ms, 1.65 s -> 1.34 s.

That one is not bit-identical - a multiply by a rounded reciprocal differs from a
correctly rounded quotient in the last place - so it can move a frame that sits
on the convergence tolerance. Battery: 21/24 space groups, no failures, and 17 of
24 crystals identical to the previous run, against a floor of 13 of 24 for the
same binary run twice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 06:29:48 -04:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-07-11 07:19:11 +02:00
2026-07-19 09:39:28 +02:00
2026-08-15 17:13:53 -04:00
2025-12-04 11:56:14 +01:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-07-13 13:54:03 +02:00
2026-07-12 19:42:29 +02:00
2026-08-13 17:03:10 +02:00
2026-03-26 20:50:33 +01:00
2026-06-23 20:29:49 +02:00
2026-08-13 17:03:10 +02:00
2026-07-19 09:39:28 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-07-19 09:39:28 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-06-13 21:27:41 +02:00
2026-06-23 20:29:49 +02:00
2026-08-13 17:03:10 +02:00
2024-11-22 21:25:20 +01:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2024-12-02 21:17:14 +01:00
2026-08-13 17:03:10 +02:00
2025-10-25 22:05:47 +02:00
2026-07-03 19:18:56 +02:00
2026-06-23 20:29:49 +02:00
2026-08-13 17:03:10 +02:00
2024-12-02 21:17:14 +01:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00
2026-08-13 17:03:10 +02:00

Jungfraujoch

Application to receive data from the PSI JUNGFRAU and EIGER detectors.

All documentation is now placed in docs/ subdirectory and for the current version hosted on Jungfraujoch Read The Docs page.

S
Description
Jungfraujoch Data Acquisition System
Readme GPL-3.0
3 GiB
Languages
C++ 74.7%
HTML 8%
C 6.4%
TypeScript 4.4%
Tcl 2.3%
Other 4.1%