Catalog and sequential kernels on WorkMeter; threads come from the execution

[alexy]

Step 5 of the order in codex-to-codex.md (2026-09-20T08:15Z). After this there is one accounting layer and one source of thread counts in grust-algorithms.

What changes

The seventeen catalog kernels move onto the surviving layer. Meter and parallel::width() are deleted. Every kernel charges through ExecutionContext::work_meter(), which admits work before it is done, so a budget is never exceeded by work already performed; the old Meter could overshoot by a block per worker.

Threads come from the execution, never from the machine. parallel::concurrency(context, units) is what the execution asked for above the shared floor, otherwise one. map_ranges, ordered_blocks, for_chunks and sort_total take that count. At one worker they run on the calling thread and do not touch rayon; above it they run inside the bounded pool for that count. Before, a kernel called outside an installed pool used rayon's global pool, which is every core of the machine.

Behaviour change: a caller that does not call with_concurrency now runs every catalog kernel single-threaded. Results are unchanged and bit-identical at any worker count. Nutmeg must pass the option through to get parallel kernels.

One meter per block workspace, not per node or per source, because creating a WorkMeter takes the grant registry exclusively.

The sequential kernels charge through a meter too: dijkstra, shortestPaths, bfs, dfs, topologicalSort, scc, wcc, and the MinHeap the path kernels share, instead of one compare-exchange on the shared counter per visited entry.

Tests

175 pass across grust-procedures, grust-algorithms and grust-algorithm-procedures with all features; clippy clean with -D warnings; --no-default-features builds. The determinism tests now ask for 1, 2, 3 and 8 workers through the context rather than installing a pool, and still assert identical bits and identical charged work. The triangle fixture grew from 12,400 to 28,700 work units: below the 16,384-unit floor it would have passed without ever going parallel. The original kernels' exact-work-charge tests pass unchanged.

Numbers, and what they are worth

Sequential kernels, a million nodes and ten million random weighted arcs, no deadline, no concurrency requested, release, best of nine, one laptop. Per-entry was measured before and again after the metered runs and reproduced within 3%.

kernel	per-entry charge_work	metered	change
dijkstra	690 ms	513 ms	-26%
bfs	312 ms	203 ms	-35%
dfs	358 ms	302 ms	-16%
scc	682 ms	563 ms	-17%
wcc	310 ms	186 ms	-40%

This is a single-host probe on one synthetic graph, not the paired benchmark harness. The harness run has been requested in codex-to-codex.md and is what should be cited.

🤖 Generated with Claude Code