Acquisition-worker loader preparation, 2026-10-23

Acquisition-worker loader preparation, 2026-10-23#

Private experiment: quantem-progressive-latency-20261023. Unpublished source checkout, not an installed-wheel qualification or a release promise.

Change and workload#

A private CUDA loader preparation helper initializes the existing header parser, decode module, and shared ANS coding tables before an acquisition arrives. It opens no source and allocates no detector-count volume. Loading still uses the public io.load path. No decoding arithmetic, scan positions, BF pixels, precision, fitting budget, or calibration changes.

Both real acquisitions contain a complete 512 × 512 scan and native 192 × 192 uint16 detector. CUDA ran on an RTX PRO 6000 Blackwell Workstation GPU, with Python 3.14.6, CuPy 14.2.0 and NumPy 2.4.6. The browser ran separately on an Apple M5 Max using hardware WebGPU. There was no competing scientific job; existing desktop/background contexts remained running.

GPU base: d2db0bdb4c9859230d3e9ba2f6b23fcfae8eb0f1 plus local changes. The full-volume benchmark records diff SHA-256 b51b0d24d1506a5b96b97e99d23b8e4efe3629fdecb13b1ee0d9e1b24dbc7dec. Concurrent MPS changes are not qualified by these CUDA observations. Live base: 20aed10c0d3a9b7d6f6db0603ab3f1ea8da723b3 plus staged-result, H5-first loading, worker preparation and immediate ready-event refresh changes. The worker source SHA-256 is 55d8ea285055efccc5a8b747684a3db7b2acfdcb9965e6a6e267932dd0cb9aad.

Measured boundaries#

These are individual observations, not median/p95 estimates. OS source pages and compiler caches were retained, not flushed; none is a cold-disk claim.

Boundary

Acquisition A

Acquisition B

Previous loading including QEM write and verification

4.610 s

4.665 s

H5-first loading, without startup preparation

1.907 s

1.874 s

H5-first loading, with startup preparation

1.295 s

1.412 s

Initial 200-trial fit, prepared worker

1.084 s

2.050 s

Additional fifth-order refinement

7.634 s

7.841 s

Initial image visible, prepared worker

4.288 s

6.599 s

Final image visible, prepared worker

12.376 s

14.679 s

Browser times start when the last staged chunk finishes writing, and include Watch readiness checks, loading, previews, fitting, saved products, transport and paint. The test deliberately holds an incomplete final chunk first; it must not start reconstruction prematurely. The initial image updates to the final image without navigation or reload. This does not establish a two-second initial browser result or ten-second final browser result.

Standalone profiling on acquisition A measured 0.307 s startup preparation, 1.019 s first load and 0.601 s repeated load. First-load host registration used 0.234 s. A separate shipped benchmark_hdf5_load.py run, after 0.202 s startup preparation, measured 0.895 s synchronized public loading. Its complete logical uint16 output hash matched the preserved reference; hashing took another 12.961 s and was excluded from loading. Existing canonical-path indexes and uncontrolled source-page reuse mean this is not a new-path arrival latency.

Scientific and UI gates#

  • Both acquisitions: all nine saved product arrays, the initial native phase, 13 fitted/calibration fields, and optimizer seeds/bounds/coordinates agree exactly with the retained pre-change run. No tolerance or reference changed.

  • Complete acquisition A logical pixels match SHA-256 9729a14aadd3bb2ffca8d85955c1bb0784a3c4d9eda657120e844b58375983b1, with source/working detector 192 × 192, bin 1, uint16.

  • The physical-CUDA synthetic regression retains uint16 values through 65535 across repeated preparation and loading.

  • Both real browser tests passed initial/final image updates, phase/FFT, native/Auto switching, and cached reopening without an implicit refit.

  • Acquisition B uses a preserved experimental calibration override, not independently verified acquisition calibration.

The initial/fifth-order optimizer remains the existing hybrid CPU numerical optimizer with CUDA objective/reconstruction. This change is startup scheduling and application IO/presentation work, not a new all-GPU solver or faster kernel. No production service restart, publication, release, or original-data deletion.