lgj-abi: hop sweeps the store ONCE, not 32 times — 3.5× at scale

[AdaWorldAPI]

Acts on ISS-LGJ-HOP-SWEEPS-FULL-POPULATION, which bench Component G opened hours earlier (#38). The measurement authorises this; nothing here is taste.

The arithmetic is why — and it isn't "too many rows"

32 × 65 536 strided u32 compares is ~2 M operations. That is nowhere near the 24 ms observed. But 32 passes over a 33 MB store, each re-reading every 512-byte row to look at 4 bytes of it, is ~1 GB of memory traffic.

The loop order was the cost, not the row count. That distinction is what makes this a re-ordering rather than a new kernel.

What changed

lgj_hop no longer loops for facet in 0..32 { sweep(all n rows) }. It calls simd_rowstore_facet_match once — all 32 facets per row, one U32x16::eq_bitmask per 64-byte chunk via MultiLaneColumn — then walks src's set rows rather than every row × facet, taking only facets that both matched and participate (facet_bits[row] & effective).

No new kernel. simd_rowstore_facet_match already existed and is the same sanctioned ndarray::simd surface (abi.md §8) — it was being consumed the wrong way round. No ABI change, no signature change, no minor bump: strictly an internal re-ordering behind an unchanged contract.

Measured — same instrument, same command

native_hop	1 % / 4096	1 % / 65536	25 % / 4096	25 % / 65536
before	479.0 µs	24 798.3 µs	521.2 µs	23 633.9 µs
after	374.7 µs	7 120.3 µs	375.8 µs	8 076.9 µs
speed-up	1.28×	3.48×	1.39×	2.93×

The control matters here. The two scalar arms are untouched code — had the second run merely landed on a faster host, they would have moved too. Measured: classidScan 150.6 → 164.2 µs and facetMatches 7 142.3 → 7 698.8 µs at 1 %/65 536 — within ~9 %, and slightly slower. So the native gain is real and if anything understated. (JMH's banner does report a different CPU string between runs, which is precisely why the control arms are quoted rather than the box assumed identical.)

Behaviour unchanged — verified, not assumed

lgj-abi 134/134 (the hop's own aliasing and semantics tests among them), AllTests 304, GraphHopTest 66 including G3 at the identical 384-byte allocation floor, TradesParity 12, TradesAllocation 3, BricksAuth 62 — 447 Java checks. clippy -D warnings and fmt clean.

Still slower than the best scalar arm — regraded, not closed

At 1 %/65 536 native is 7 120 µs against classidScan's 164 µs — 43×. The catastrophic term is gone; a structural one is not.

simd_rowstore_facet_match still sweeps the whole population: the decode half is now frontier-bounded, the compare half is not. The issue is marked RESOLVED IN PART, not resolved.

The next rung is a genuinely different shape — gather per src row, O(frontier) instead of O(population) — and it is not obviously better, because a dense frontier should favour the sweep's sequential access. That is a real density crossover, so it is a measurement rather than a judgement call, and Component G is now the instrument that can find it.

Why not both at once

The one-pass change is bounded, needs no new kernel, has no crossover, and is strictly less work at every point in the measured space. The gather rewrite is none of those. Landing them together would make a regression in either impossible to attribute.

Board hygiene

Same commit: ISSUES regraded with what remains open and why the split; RESULTS.md § G carries the before/after table, the control-arm reasoning, and the named remaining gap.

---

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: 82b8c1cd-a35b-469d-9e09-3559bdaa4f57

---

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_5f5314c8-3626-4810-9ad4-f47f31ca2e21)