bench: Component G — the F-PARITY harness, measured; W8 FALSIFIERS + POLICY closed

[AdaWorldAPI]

Closes the last two rungs of D-LGJ-W8. Both were narrower than the board said, and one was already done.

Scoping first, because it changed the work

§12 says "W8 carries only those marked [W8]" and marks exactly two of eight F-*. The other six (F-PAR/F-ORD/F-ONE/F-SPARSE/F-ACK/F-LAND) are pre-registered for the compute wave. The board's "spec §12 F-* pre-registrations" wording implied all eight.

• F-HYDR was already shipped — GraphHopTest's G3 gate, allocation flat at a 384-byte floor across 10-vs-500 rows.
• F-PARITY is this PR.

POLICY was discharged at the A3 freeze (PR #20), not last. §3.9 lands the policy artifacts "BEFORE workers", and every one exists dated 2026-08-18: root CLAUDE.md (incl. §13's compute additions), EPIPHANIES.md:683 storno, the STATUS_BOARD row, LATEST_STATE, PR_ARC_INVENTORY. The ladder's … → FALSIFIERS → POLICY ordering is misleading; the board carried POLICY as remaining for nine days.

Component G

G_HopExecutionBoundary — native lgj_hop (mask in, mask out, no row id ever produced) against the two scalar oracles preserved verbatim from GraphHopTest. Reused rather than rewritten precisely because they are already cross-checked against each other and against native on every change, so a divergence here is real rather than a fresh transcription bug.

Swept on both axes §3.8 requires: rows {4096, 65536} × frontier {1 %, 25 %}. All three arms must agree on the destination set in @Setup before anything is timed, plus an anti-vacuity guard refusing a fixture whose hop reaches nothing.

The Vector-API arm §3.8 calls "optional" is absent deliberately, and the class says so: it would be a second implementation of the kernel, and building one before the scalar arms had been measured is exactly the taste-before-measurement §3.8 forbids.

And it was measured, not merely seeded

JMH jars fetched per README, .so built, full sweep run.

arm	1 % / 4096	1 % / 65536	25 % / 4096	25 % / 65536
java_scalar_classidScan	8.5 µs	150.6 µs	204.0 µs	7 173.6 µs
java_scalar_facetMatches	394.9 µs	7 142.3 µs	433.8 µs	10 071.5 µs
native_hop	479.0 µs	24 798.3 µs	521.2 µs	23 633.9 µs

Native is slowest at every configuration, 2.6×–165×. The ranking is the less interesting half — the shape is the finding:

• Flat in frontier density. 479 → 521 µs at 4096; 24 798 → 23 634 µs at 65 536. A 25× bigger frontier costs nothing.
• Linear in population. 16× the rows → ~52× the time.

A hop whose cost tracks the population it ignores rather than the frontier it starts from is doing full-population work.

Root cause, localized — exports.rs:1589-1599

for facet in 0..ROW_FACETS {                        // 32 facets
    if (effective >> facet) & 1 == 0 { continue }
    kernels::simd_rowstore_classid_mask(bytes, …, n, …)   // n = ALL rows
    for (w, (&sw, &cw)) in src_snapshot.iter().zip(classid_scratch.iter()) { … }
}

The classid mask is built across the whole population once per participating facet — 32 full-width sweeps per hop — and only then intersected with src. The decode/scatter half is frontier-bounded; the sweep before it is not. ~2.1 M strided classid reads per call at 65 536 rows before one edge is decoded.

Filed as ISS-LGJ-HOP-SWEEPS-FULL-POPULATION.

The remedy is deliberately not in this PR

src_snapshot is known before the loop, so the sweep could be bounded to words where src has bits, or skipped for a facet whose intersection is empty. That is a kernel change, and §12 scopes W8's F-PARITY to "seeds the HARNESS only" on a component §3.8 declares non-gating. A kernel rewrite inside a bench commit widens the PR past what the measurement authorises.

What this does not say

Not a verdict on mask-native execution. Allocation independence is pinned separately (G3) and unaffected; the no-row-id guarantees are structural. This is the throughput-placement axis §3.8 says a measurement decides — "Promotion/demotion of the placement follows that measurement — never taste." It now has one.

Caveats carried, not buried (in RESULTS.md and ISSUES.md both): the per-call Engine.createMask + close has no scalar analogue and was not isolated — implausible as the story at 470 µs on 4096 rows, and it would not scale with rows, but named anyway. Native absolutes are noisy (±12 844 on 24 798) on a shared 4-vCPU container: the ordering is robust, the absolutes are not. One machine, one run.

Component G writes its own results/jmh-results-G.csv — different fixture, different axes, deliberately not merged into the A–F tables. (The first run overwrote jmh-results.csv; caught by git status and restored.)

Also corrects a stale cross-repo claim — in the file that exists to prevent them

WAVE_STATUS_CHECKLIST.md said ruff_r2il PR2 was a "drill-down proposer" gated on PR1 corpus numbers, both unmerged. Measured against the repo:

claim	reality
PR1 unmerged	DONE — CORPUS-PROFILE-RESULT.md, 100.00 % inline fit on all four binaries
PR2 unmerged	DONE — ORACLE-RESULT.md, zero mismatches over 35,946 matched op sites
PR2 = "drill-down proposer"	never was — the PR2 gate deliverable is the round-trip oracle

The real open item is O6 (the MemorySpace schema-widening decision), which scopes O5/PR3's ogar_codebook mint. Wrong text quoted rather than deleted, per append-only.

Board hygiene

Same commit, per the rule: STATUS_BOARD row flipped to D-LGJ-W8 COMPLETE, ISSUES entry, checklist correction.

Gates

• bench compiles clean under run.sh's exact command line (javac -proc:full, JDK 26.0.2)
• Component G's @Setup cross-check passed at all four configurations — the harness gating itself
• No production code touched: this PR adds a bench class, a CSV, and docs

---

Generated by Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2132c41e-2262-4553-bd5f-6d21684fd25a

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_668e0561-aad8-4e52-a71a-dd3b4108e738)