[DO NOT MERGE AS-IS] hop as AND over a memoised per-facet mask — measured, conditional

[AdaWorldAPI]

Not recommended for merge as-is. It works, it's fully gated, and it wins by up to 13.5× warm — but it is a 2 500× regression cold. The branch exists so the work and its numbers aren't stranded and the choice gets made on data. Options at the bottom.

The framing was right, and sharper than mine

"A masking sweep is an AND." The hop decomposes four ways and only the last resists mask algebra:

step	mask algebra?
classid(row, facet) == needle	yes — a mask
payload_hi32 == 0	yes — a mask
∩ src	yes — the AND
dst[decode(row, facet)] = 1	no — data-dependent scatter

The gather #40 shipped had traded the algebra away: the classid predicate stopped being a mask and became an inline byte compare. The contract held — no java/, no abi.md, no minor bump, GraphHopTest's allowlist + G2 + G3 green at the identical 384-byte floor — but the structure didn't.

What this adds

RowStore::facet_bits(classid) -> Arc<[u32]> — one 32-bit mask per row of which facets carry that class, built once through the sanctioned simd_rowstore_facet_match kernel, shared by refcount after. lgj_hop becomes facet_bits[row] & effective — an AND — plus the irreducible scatter.

No invalidation needed: RowStore exposes no &mut self method, so the buffer is immutable for the store's life. Bounded at 4 classids (n_rows × 4 bytes each).

Measured — and the answer is conditional

Component G, 65 536 rows:

density	gather	memo cold	memo warm
0.01 %	2.7 µs	6 901.7 µs	2.8 µs
1 %	46.8 µs	6 984.0 µs	10.1 µs
25 %	3 673.3 µs	7 647.6 µs	271.5 µs
100 %	6 070.2 µs	9 828.7 µs	1 952.3 µs

Warm, the AND wins everywhere — up to 13.5×. The mask is the right shape once it's paid for.

Cold, it's flat at ~6 900 µs at every density, because the O(n) build dominates. At 0.01 % that's 2 500× worse than the gather. Break-even: ~190 hops at a 1 % frontier, ~2 hops at 25 %+.

The three options

1. This, unconditional — best for deep/dense traversal, worst case 2 500×.
2. Keep lgj-abi: hop gathers instead of sweeping — the predicted crossover does not exist #40's gather (what main has) — no regression anywhere, leaves 13.5× on the table for repeated dense hops.
3. Lazily-filled mask — fill each row's u32 during the gather that first touches it, with a per-row filled bit. Cold ≈ gather, warm = the AND, no O(n) build ever, no tuning knob. Bounded downside; upside depends on rows being re-hopped, which is not measured. ← recommended, pending that measurement.

A separate finding — one variable at a time

The first run of this change was on JDK 27 and looked like a further win. Re-running the same binary on JDK 26:

	1 %/4096	1 %/65536	25 %/4096	25 %/65536
JDK 26	0.984	10.856	7.367	250.0
JDK 27	1.002	10.713	7.694	262.5

Within ~5 %, JDK 26 marginally faster. The JDK contributes nothing, which confirms by measurement what the source already said: grep finds zero value record / value class in java/src/main/java, so JDK 27 is a different JIT and no Valhalla flattening.

Every Component G number in this repo — past and present — includes ordinary heap allocation for the per-hop Mask and WideFieldMask wrappers. Panama is real and measured; Valhalla has never run outside valhalla-lab.

Also fixes a doc comment this change displaced: inserting facet_bits above bytes_arc orphaned the latter's doc onto the former. Caught by clippy's missing-docs gate, not by reading.

Gates

lgj-abi 134/134; AllTests 304, GraphHopTest 66 (G3 unchanged), TradesParity 12, TradesAllocation 3, BricksAuth 62 = 447 Java checks; clippy -D warnings + fmt clean. No ABI change, no minor bump.

Evidence: .claude/board/hop-memoisation-cold-vs-warm.txt — five populations × twelve densities, all four shapes, equivalence asserted at every point.

---

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: 42f8b775-5390-4431-9b16-c3b6fc10eca4

---

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_7ab3d8b0-e173-4423-902e-8ef028e78dc1)