Exact

Exact Union RegExp

Repository files (latest commit first)

Filename	Latest commit message	Latest commit date
Transaction Science 5208dc5936 mesh: withdraw the GPU per-decision figure — another process held 99.5% of the GPU ... I reported 0.104 J per three-question decision as GPU 0.0966 J plus process CPU 0.0075 J, and put it in SPEC §3.6's worked example. The GPU half does not hold. `gpu_share.py` measures the thing I had assumed away: per-process GPU time from `accumulatedGPUTime` on each IOUserClient in the IOAccelerator subtree, as a **delta over the span** rather than the cumulative totals (which are useless — WindowServer has days of accrued time). Over a 4.06 s span with an MLX matmul loop running, **com.apple.Safari held 2.470 s of 2.482 s — 99.5%** — while this process registered 0.000 s. The host was at load average 132 on 18 CPUs, running another session's VVC/VTM encodes, which is this machine's normal state rather than an unlucky moment. A rail delta over that span is a reading of Safari. The rule already shipped elsewhere in the fleet is the right one: attribute a rail reading to this process only when it holds ≥99% of the GPU time advancing in the span, report exactly zero when it holds none, and otherwise **issue no GPU figure**, marking the span CPU-only and partial. By that rule this measurement issues none. The 0.08% idle-bracket correction I cited as evidence of cleanliness proves nothing, and I should not have read it that way: a bracket subtracts *steady* background, and cannot subtract a contending process whose work overlaps the span but not the brackets. What stands, and why it is the more interesting half: the **CPU** figures are untouched — Laya 0.486 J and GLiNER2.5-Decide 0.555 J per three-question decision — because the kernel's per-process counter attributes to a principal, so neither load average 132 nor Safari's GPU work enters them. That is exactly what `Attribution::Process` is for, and it took a contaminated GPU figure to demonstrate it. SPEC §3.6's worked example now uses the CPU figure (486 000 µJ, 162 mJ per answered question) and says why it is not the GPU one. Latency figures are unaffected. Also corrects the direction of my earlier framing. I presented the GPU path as "4.7× cheaper, and the price is that it cannot be bound to a principal". The truth is stronger: on a shared host it cannot be bound to a principal *and* the number itself is not the workload's. A sound GPU figure needs a host with no display server and no other GPU client — on this fleet, a headless Linux box with NVML, not a Mac. `gpu_rail_period.py` is also added, the harness behind 92449670's correction of the rail's declared period. Co-Authored-By: Claude Opus 5 <[email protected]>		2026-10-05 07:20:58 -04:00
..
crates	mesh: withdraw the GPU per-decision figure — another process held 99.5% of the GPU	2026-10-05 07:20:58 -04:00
Cargo.lock	chore(deps): cargo update across the workspace; eoc toolchain → 1.98.0	2026-08-26 07:39:26 -04:00
Cargo.toml	msrv: raise the rust-version floor to 1.97 across the workspaces	2026-07-23 00:17:08 -04:00