ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

moby_classes.offset enrichment is size-independent: 13x to 72x at matched size

Browse Source 
Runs the control 06531fb named. It settles the question that commit left open,
and the answer is that the enrichment is real.

Matching on immediate-set size, against the best of the sixteen adjacent values:

    bucket      n   0xc0   best neighbour   ratio
       0-15  1,082     72   0xb8:1             72.0x
      16-31    713    119   0xc8:4             29.8x
      32-47    291    104   0xb8:3             34.7x
      48-63    119     39   0xb8:2             19.5x
      64-79     59     31   0xc8:2             15.5x
      80-95     25     13   0xb8:1             13.0x

Enriched in every bucket, and the ratio does not decay as sets grow. That is the
opposite of a pigeonhole artifact -- a volume effect would shrink the ratio in the
big buckets, and it rises instead.

The load-bearing row is the smallest: 72 of 1,082 functions carrying fewer than 16
distinct immediates contain 0xc0, where the best neighbour appears once. A set that
small cannot produce that by count alone.

What this revives. The 300 candidates with 48 or fewer distinct immediates are not
noise: at matched size, neighbours hit 0.4% to 1.4% in those buckets where 0xc0
hits 35%. A function using fewer than 16 constants, one of which is 0xc0, uses
that offset deliberately. Those are the shortlist.

Why this took four commits to establish. 3ea5ab7 measured 394 against neighbours
1-14 and called it a shortlist. 06531fb showed the rate rises with set size and
said the 394 was a list of large functions. Both were right about their own
measurement and neither had the bucket-matched comparison, which is the only form
that separates "the constant is special" from "big functions contain more
constants". Twenty-two probes this stretch, and the thing that finally settled it
was not a better measurement but adding the right comparison to a measurement
taken three commits earlier.

Caveat unchanged: presence of an immediate is not proof the chunk is read there.
It is proof the constant is used, which is all either test asserts.

284 passing with the disc present (23 + 19 + 64 + 156 + 22; disc binary ~35s),
clippy clean.
This commit is contained in:
ReaperOfVeriod
2026-10-14 05:34:42 +02:00
parent 06531fb66c
commit a2f8c924b4
3 changed files with 172 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/level-assets.md
+29 -6
View File
@@ -2100,9 +2100,32 @@ This does **not** retract the neighbour result. `0xc0` being enriched over
and both can hold. What it retracts is the inference that the 394 are candidates
for anything.
**The control that would settle it, not yet run:** `0xc0`'s rate against a
*specific neighbour's* rate **within the same set-size bucket**. If `0xc0` runs at
35.7% in the 32-47 bucket while `0xb9` runs at 3% in that same bucket, the
enrichment is size-independent and real. Until that is measured the honest summary
is that the loader hunt has a robust *fact* (the constant is used far more than
adjacent constants) and no *shortlist*.
**The control that would settle it:** `0xc0`'s rate against the best of its
sixteen neighbours, **within the same set-size bucket**.
bucket n 0xc0 best neighbour ratio
0-15 1,082 72 0xb8:1 72.0x
16-31 713 119 0xc8:4 29.8x
32-47 291 104 0xb8:3 34.7x
48-63 119 39 0xb8:2 19.5x
64-79 59 31 0xc8:2 15.5x
80-95 25 13 0xb8:1 13.0x
**Enriched in every bucket, 13x to 72x, and the ratio does not decay as sets grow.**
That is the opposite of a pigeonhole artifact -- a volume effect would shrink the
ratio in the big buckets, and it rises instead.
The load-bearing row is the smallest. **72 of 1,082 functions carrying fewer than
16 distinct immediates contain `0xc0`, where the best neighbour appears once.** A
set that small cannot produce that by count alone. The constant is genuinely
special, and the fact is size-independent.
**What this revives.** The 300 candidates with 48 or fewer distinct immediates
are no longer noise -- at matched size, neighbours hit 0.4% to 1.4% in those
buckets where `0xc0` hits 35%. A function using fewer than 16 constants, one of
which is `0xc0`, is a function that uses this offset *deliberately*. Those are the
shortlist, and `moby_classes_offset_enrichment_survives_set_size_matching` is the
test that will catch them being thrown away again.
Still true and still worth saying: presence of an immediate is not proof the chunk
is read there. It is proof the constant is used, which is all either test asserts.