Inference programme: no fast default CPU mesh — Rectangular is the default and slow on CPU (new-user hazard)

[Jammy2211]

Bolt-on to the JAX profiling / inference programme (results/notes/inference/PROGRAMME.md; PyAutoMind epic jax-inference-profiling). Filed 2026-08-21 from the CPU-likelihood speed campaign (#151), at user direction.

Problem

After the 2026-08-20/21 CPU speed round, the Delaunay + Hilbert AdaptImage fiducial is fast on CPU (euclid 4.92 → 1.34 s/eval via PyAutoArray#453 + #455) — but it is the expert configuration. The default mesh a new user gets is RectangularAdaptDensity, whose kernel-CDF transform makes it the slowest thing on a CPU:

• euclid: transform = 1.66 s = 55% of the eval; hst: 27 s = 89% of a 21.6–30 s eval.
• The exact windowed numba kernel (PR in flight) buys 3.0–3.4×, but the transform is irreducibly O(N²) erf for exact values — hst stays ~8 s/eval, and the O(N²) scaling gets worse at JWST resolution.
• A config-gated interpolated-CDF forward (K=8192 knots) was measured at Δlnℒ ≤ +4e-3 absolute / ≤ 2e-3 differential (passes the rtol 1e-6 pins) and reaches ~18–55× on the step — but it is an approximation and a defaults/science decision.
• On GPU this is a non-issue (full hst eval 57.6 ms on A100) — the hazard is specifically CPU users on the default configuration, i.e. exactly the audience of cpu_fast_modeling.py and every new user without a GPU.

Options (decision needed, then a programme slice)

1. Make Delaunay first-class: it is now the fast CPU mesh, but requires the adapt-image machinery (Hilbert image mesh from a prior fit) — first-class means either a sensible no-adapt entry path (e.g. Overlay image mesh) or chained-fit defaults that hide the setup from new users.
2. A simpler/faster Rectangular default: plain uniform Rectangular (no kernel-CDF adaption) as the CPU default, and/or ship the interpolated-CDF mode as the CPU default with the exact transform config-gated instead (inverting the gate).
3. Something else — e.g. backend-dependent defaults (adaptive Rectangular on JAX/GPU where it is free; a cheaper mesh on use_jax=False), or resolution-dependent guardrails that warn when the O(N²) transform will dominate.

Evidence base

• Kernel-CDF cost + exact-numba prototype + interp-accuracy measurements: PyAutoMind draft/feature/autoarray/numba_cpu_likelihood_kernel_cdf_fast_path.md (prototype header, 2026-08-21) and this repo's perf: numba CPU sparse-operator likelihood profiling infrastructure #151 findings trail.
• Delaunay CPU campaign results: perf: numba CPU sparse-operator likelihood profiling infrastructure #151, PyAutoArray#452–#455.

Suggested handling: add a backlog row to PROGRAMME.md and adjudicate the default-mesh decision at the next programme gate — the engineering slices (whichever option wins) are all small once the decision is made.

[Jammy2211]

Phase 14 default-mesh decision: adjudicated 2026-08-21 — option (2), in the "resurrect the empirical rank-CDF transform" form (task PyAutoLabs/PyAutoArray#461).

The rectangular adaptive mesh family is now split in PyAutoArray (PR PyAutoLabs/PyAutoArray#462, merged):

• RectangularBilinearAdaptDensity / RectangularBilinearAdaptImage — the empirical rank-CDF transform (sort + cumsum, O(N log N), no hyperparameters), recovered from the pre-#402 implementation. This becomes the workspace default (PRs autolens_workspace#495, autogalaxy_workspace#221), eliminating the O(M_sub × N_data) erf sum that is 55% (euclid) to 89% (hst) of the numba CPU eval.
• RectangularRTUAdaptDensity / RectangularRTUAdaptImage — pure renames of the kernel-CDF classes; the advanced option for GPU, JAX gradient samplers, and the interferometer sparse path (where Bilinear is permanently gradient-dead — no over-sampling exists). Docs state: gradient users set over_sample_size_pixelization >= 4 (imaging) or use RTU.

What this leaves for this issue / the PROGRAMME:

• The interpolated-kernel-CDF forward (K=8192, ΔlnL ≤ +4e-3, 18–55× on the step) was deliberately not used for the Bilinear pair (it is still RTU with a bandwidth hyperparameter); it remains this issue's lever for making RTU itself faster on CPU, if still wanted now that the CPU default is rank-CDF.
• A versioned Bilinear measurement in the pixelization_numba likelihood-runtime cells is still to be recorded here.
• results/notes/inference/PROGRAMME.md Phase 14 (status table row + §Phase 14) should be flipped from "awaiting adjudication" to decided when this repo's in-flight branch (feat: numba CPU sparse-operator likelihood profiling (runtime, breakdown, multiprocessing scaling) #152) lands — not pushed now to avoid crossing that PR.

---

Generated by Claude Code