Repository navigation
One-thread-worker scans have no measurement on native #314
Description
SEP 43 retired numba_cpu with the gaps below stated (§2). The first two are closed by that decision, and 0.1.0 can still produce those rows. The scan question stays, for native.
What is missing
SEP 29 asked for the core cases, native against numba_cpu, at one thread and the production width, on each wheel family, once the first release was out. The 0.1.0 record (#68), taken 2026-11-01 from the release's wheel, does most of it. All 22 configurations ran on both backends with the same accepted steps, on three of the CPU hardware sets (compared row by row in the files). As #140 reports them, numba_cpu's time over native's, geometric mean:
| machine | 1 thread (10 cases) | all cores (12 cases) |
|---|---|---|
| 2x Intel Xeon Gold 6240 (36 cores) | 2.19 | 2.84 |
| AMD EPYC 7763 (16 cores) | 1.95 | 2.39 |
| Apple M5 Max (18 cores) | 1.53 | 2.11 |
Three gaps remain, each checked by counting rows in the history files:
- Two wheel families have no
numba_cpurows: Windows x86-64 and Linux aarch64 (and the x86-64 AMD EPYC 9B45 has none either). The earlier SEP 29 baselines for those predate the native Adams work. - The Apple M5 Max series is unreliable. 19 of its 22
numba_cpurows are flaggedbusy, against 4 of 22 native, so its factors may overstate the gap. - Scans are unmeasured. Use the native backend by default: the docs say so, and
autowarns onnumba_cpu#140 removes the advice that one-threadnumba_cpucan match native in a scan of one-thread workers, because no case in the history shows it, but as it says, the history times a single process. Older ledger entries have native at 0.91 to 1.07 timesnumba_cpuat one thread. Neither has been measured side by side.
Why it matters
#140 is what makes numba_cpu a warned fallback, and #316 needs this evidence, so what users are told rests on it. Nothing has been run for this issue.
To do
- Time a scan of N one-thread workers, with N the core count, against one N-thread process over the same points, on native on a many-core x86-64 machine, on a capillary and a GNLSE case, and add the result to the ledger.
Must not change: how the history compares rows (within one backend).
Done when
The ledger holds the scan comparison with machine, width and date. The guidance in backends.md and tuning.md agrees with it.
Checked against commit 8a9f764. Takes over the roadmap's entry "Per-platform performance of the wheels".
Activity
[-]`numba_cpu` against native: no rows on Windows or Linux aarch64, a busy Apple M5 Max series, and scans unmeasured[/-][+]One-thread-worker scans have no measurement on native[/+]SEP 46: Final
jtravs commentedon Nov 9, 2026
SEP 46's scan-worker measurement (#582;
docs/dev/benchmarks.md, "Scan workers calibrated on an AMD EPYC 7763 node") gives one-thread-worker scans on native a first measurement. On a whole node of two AMD EPYC 7763 (128 cores, GCC 16), an RDW tuning scan (a four-mode helium capillary, 5 cm, over 20 × 20 pressures and energies) onPoolwith 128 one-thread workers took 464, 690 and 415 s in three rounds. The first scan of each round was the slowest, whichever arm it was.It doesn't answer this issue's question, workers against threads a worker at equal points. The same node's 8 × 16 and 4 × 4 configurations ran only 16 points each, so their throughput isn't comparable. The calibration also leaves a one-CPU worker on the built-in table, since one CPU has nothing to choose.
🤖 Generated with Claude Code