R1 — the hop's selection is mask algebra again (and R2 is measured, not landed)

[AdaWorldAPI]

There is no gathering. Walking src's set bits is a serialization of a population that is already there — avoiding the Vec and doing it with a loop counter is the same act in the time dimension.

R1 — what changed

lgj_hop selects with src ∧ class_f ∧ struct_f, word-parallel. No row is examined to decide whether it participates. The walk only emits from the result, and only because the destination index is decoded from the selected row's payload — the operand of a permutation, not a decision about membership.

F2, which no PR in this arc had caught: the structured-edge gate payload_hi32 != 0 was an if inside the row walk in every version, PR #22's clean one included. It is a per-row equality against zero — the same strided primitive as the classid match, twelve bytes further into the facet. simd_rowstore_u32_eq_mask takes an arbitrary first_offset:

predicate	first_offset	needle
facet f carries class E	f*16 + 0	E
facet f is a structured edge	f*16 + 12	0

One call site, zero new kernels.

facet_bits / facet_cache / FACET_CACHE_SLOTS deleted. Under the format-string reading of the 4+12 facet — classid -F payload, PowerShell "{0} {1}" -F $1, $2 — the memo cached the interpolated string. The projection is applied at read, never stored.

Byte-identical: 134/134 Rust incl. the pinned 10/19/29 regression (which is the proof the answer didn't move), 447/447 Java unchanged.

…and it is a 19× regression as it stands

Stated up front because it is the finding, not a side note. 65 536 rows:

	0.01 %	1 %	25 %	100 %
sweep (shipped pre-R1)	5 147	3 034	2 969	5 252
gather (#40 — the serialization)	1.0	27.7	1 659	3 880
mask algebra, AoS (R1)	41 600	49 667	48 604	51 329
columnar plane (R2 probe)	902	1 066	1 367	2 271

(µs, median of 7, release, shared container. Equivalence asserted at every configuration — all four shapes byte-identical.)

32 facets × 2 predicates = 64 whole-population passes at stride 512, ~2 GB of traffic to read 512 KB of classids. 1 024 rows → 144 µs; 65 536 rows → 40 632 µs — 282× for 64× the rows, cache and TLB failing together.

The algebra is right; the layout is the defect. R11 (#31) priced it at 9.2× before this arc began. PR #40 diagnosed it as an algebra defect and banked the opposite as a law — a measurement taken inside the defect, generalised as a property of the operation. Superseded here.

R2 — measured as a lab arm, not landed

R11's precedent: measure the layout before changing the store. The correction the measurement forced is that "give classid its own lane" is still 32 strided passes — the canvas is the (row × facet) plane, not the row. Same 512 bytes, field-major:

• class and struct are one contiguous pass each, no stride;
• participation is periodic — 64 slots per word is exactly 2 rows × 32 facets, so the operand is one repeated u64, not a buffer;
• src expands 1 row-bit → 32 slot-bits by splat.

Four operands, three ANDs, and not one built by asking which rows were selected. ~40× the AoS mask shape, 2.3–5.7× the sweep, beats the gather outright at full density — and cost tracks the canvas, not the frontier: 2.5× across a 10 000× density range.

Honest boundaries

• At a sparse frontier the gather is still faster in absolute terms — any whole-plane op is O(population), a walk is O(frontier). Not a defect to fix; it is the trade the doctrine makes, and it is why the flat-in-density columnar number matters more than the sparse comparison.
• The columnar store is not landed. The probe builds the plane from the AoS buffer; a columnar store builds it at generation. Until then lgj_hop is lawful and slow, and that trade is deliberate: the currency stays correct and the physical layer is the named blocker.
• One machine, one run, shared 4-vCPU container. Ordering is robust; absolutes are not.

Board: LATEST_STATE entry, ISS-LGJ-HOP-LAYOUT-BLOCKS-THE-ALGEBRA, raw output at .claude/board/hop-mask-algebra-vs-columnar.txt — all in this commit.

---

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: ae73b1e4-6fa7-4ebd-8922-3b0175f9e524

---

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_2b106312-e236-4fdc-b4e4-96b9ea7abeda)