docs: the mimalloc arm, re-run directly — fixes cost 30 instructions in 108M

0.4.0 claimed "no perf cost" from a fixed-vs-pristine comparison. Rebuilt the
vendored mimalloc oracle and re-ran all four arms LD_PRELOADed into one neutral
C churn binary, so the allocator is the only variable:

  glibc         160,220,039
  mimalloc       95,170,830   1.0000
  ra 0.3.2      107,943,033   1.1342
  ra 0.4.0      107,943,063   1.1342

fixed/pristine = 1.00000 — thirty instructions in 108 million. That settles
"did seven fixes cost anything" with a count rather than an estimate.

It also adds an UNflattering caveat that belongs in the README: on this
allocation-churn microbenchmark rusty_alloc is 13.4% behind mimalloc, where the
headline lua/perl/sqlite arms read 0.99-1.01. Both are true — real programs
dilute allocator cost, a malloc/free loop does not — so "at parity" is now
explicitly scoped to the workloads it was measured on rather than stated as a
general property. Still 0.67x glibc on the same workload.

No code change; docs and README only.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: tim-almond-house

README.md

@@ -59,6 +59,14 @@ The null arm is **1.17%** — wider than either effect. The honest reading is
 **"at parity, below measurement resolution"**. Reproduce on a quiet box with
 `N=31 bash bench/wallclock.sh`.
 
+**Scope that claim to these workloads.** A 0.4.0 re-run against the same
+mimalloc oracle, but on a pure allocation-CHURN microbenchmark (all arms
+`LD_PRELOAD`ed into one neutral C binary, instructions retired), reads
+**1.1342 × mimalloc** — 13.4% behind — while still being **0.67 ×** glibc.
+Real programs dilute allocator cost among everything else they do; a loop that
+does almost nothing but `malloc`/`free` does not. "At parity" is measured on
+lua/perl/sqlite and should not be read as a general property.
+
 **Not measured, and therefore not claimed:**
 
 - The full mimalloc-bench corpus. Three workloads, not the suite — the

docs/LEDGER.md

@@ -24,9 +24,31 @@ from instructions retired, which has no noise floor:
 
 2,112 instructions in 230 M. Expected: the fixes add predictable early returns
 on the adopt/retire COLD paths and touch the malloc/free fast path not at all.
-Parity with mimalloc is preserved transitively — the fast path does identical
-work to the version that measured 0.99–1.01 against mimalloc — though that arm
-was not independently re-run here.
+
+**The mimalloc arm, re-run directly** (oracle rebuilt from the vendored
+submodule; all four arms LD_PRELOADed into the SAME neutral C churn binary, so
+the allocator is the only variable):
+
+| arm | instructions retired | vs mimalloc |
+|---|---:|---:|
+| glibc | 160,220,039 | 1.6835 |
+| mimalloc v2.4.5 | 95,170,830 | 1.0000 |
+| rusty_alloc 0.3.2 (pristine) | 107,943,033 | 1.1342 |
+| **rusty_alloc 0.4.0 (fixed)** | **107,943,063** | **1.1342** |
+
+**fixed / pristine = 1.00000** — thirty instructions in 108 million. That is the
+definitive answer to "did seven fixes cost anything": no, and it is a count, not
+an estimate.
+
+**A caveat this measurement adds, and it is not flattering.** On this
+allocation-CHURN microbenchmark rusty_alloc is **13.4% behind mimalloc** —
+whereas the README's headline arms (lua/perl/sqlite under LD_PRELOAD) read
+0.99–1.01. Both are true and they do not contradict: real programs dilute
+allocator cost among everything else they do, while this workload is almost
+nothing but malloc/free. The honest reading is that **parity is workload-
+dependent, and the "at parity" claim should be read as scoped to the three real
+programs it was measured on** — not as a general property. It also remains 33%
+cheaper than glibc on the same workload.
 
 **A surprising number that was WRONG, kept as a warning.** The first xmalloc
 reading was **4.86×**. Re-run three times per arm it is 203.3 M both ways: the