valhalla-lab: R11 — the physical layout is a schema; SoA lanes measured 9.2x - #31
Merged
Conversation
…ed 9.2x Answers "would it be difficult to nudge Valhalla/Panama through 32x12-bucket SoA" with a measurement and a structural finding. The measurement: one-facet sweep over 65,536 rows, ~12-13 ns/row under today's AoS 512-stride vs ~1.30 ns/row under a true SoA facet lane -- ~9.2x. Line arithmetic alone predicts 4x (16 of 64 B used per line vs all 64); the rest is sequential prefetch plus 32x denser TLB coverage (256 rows/page at stride 16 vs 8 at stride 512). An earlier note here called the 4x "arithmetic, not a result"; it is now a result, and it was an underestimate. Checksum parity across all 32 facets pins that the two layouts are READINGS of the same logical content, so the difference is layout, not data. The structural finding outranks the ratio: ONE projector ran both layouts, selected by a LayoutSchema record -- data. No Java type changed. Valhalla is untouched by construction: what crosses is still a <=4-B group; only offsets moved. And the native kernels are already stride-parameterized (masked_strided_group_sum, eq_u32_strided_to_mask), so the same holds below the membrane -- AoS is stride 512, an SoA lane is stride 16, one code path either way. The layout was already data at every boundary except the store's constructor. Honest scope: a whole-ROW consumer inverts the preference (AoS is the contiguous layout for "all 32 facets of one row"), which is exactly why the layout is a per-workload SCHEMA rather than a fixed choice. Not measured: writes, generation, or Lance's own on-disk columnar behaviour.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 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. Comment |
Bugbot couldn't run - usage limit reachedBugbot 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_58103dfa-8905-4d35-9557-96f0ec96b630) |
AdaWorldAPI
marked this pull request as ready for review
August 25, 2026 14:43
AdaWorldAPI
pushed a commit
that referenced
this pull request
Aug 27, 2026
PR_ARC_INVENTORY had entries for #1-#12, #14, #16, #18, #20 and #32, and nothing else. Missing: #13, #22-#31, #33-#41 — twenty PRs. (#15/#17/#19/#21 are also absent and correctly so: each is itself an arc-entry-only PR, exempt under the termination clause.) #32's own entry still read "(draft, opened …)" with no merge sha. Corrects this branch's first count, which said nineteen and read the gap as starting at #21. Both were wrong — it is twenty, and it starts at #13. The first count was a range subtraction over a file with holes; the enumeration is what found the difference. Method, which is the point rather than an aside: each entry drafted from that PR's own body and diff, five parallel agents over four PRs each, none permitted to work from a later session's recall. Every backfilled entry's Confidence bullet ends "Backfilled 2026-08-27 from the PR body and diff, not written at merge time", so reconstructed entries are distinguishable from ones written at merge time; several state which claims are the PR body's own and were not re-verified. Every cited sha, date and merge-vs- squash label machine-checked against git. Four things the backfill turned up, each recorded in the entry it belongs to: #25's body asserts "no code, no reproducer changes" and its own diff contradicts it; #39 left its lgj_hop doc comment describing the pre-change design; #34's banked evidence file did not identify its own JDK; and #41 is on main while its own title reads [DO NOT MERGE AS-IS], recorded as unresolved disposition rather than an endorsement. ISS-LGJ-ARC-INVENTORY-STOPPED-AT-32 moves to RESOLVED with the corrected count and the standing rule restated: the entry goes in at open, in the PR's own commit. The backfill is the repair, not the process. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DCfrD5y19cvFc4AoyydXYv
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lab-only, no ABI change. Answers "would it be difficult to nudge Valhalla/Panama through 32×12-bucket SoA?" with a measurement and a structural finding.
Measured: ~9.2×, and the 4× prediction was an underestimate
One-facet sweep, 65,536 rows, same logical content under two layouts (checksum-parity-pinned across all 32 facets):
Line arithmetic predicts 4× (16 of 64 B used per line vs all 64). The rest is sequential prefetch + 32× denser TLB coverage (256 rows per 4K page at stride 16 vs 8 at stride 512). An earlier note in this repo called the 4× "arithmetic, not a result" — it is now a result.
The structural finding outranks the ratio
The layout was already data at every boundary except the store's constructor.
LayoutSchemarecord — the "schema apply" is a descriptor swap, not code.masked_strided_group_sum,eq_u32_strided_to_mask): AoS is stride 512, an SoA lane is stride 16, one code path either way.LgjLaneDeschas carriedstride_bytessince minor 1.So the ABI-side cost of a real SoA store is an additive constructor + lane descriptors — not a kernel rewrite and not a Java rewrite.
Honest scope
A whole-ROW consumer inverts the preference (AoS is contiguous for "all 32 facets of one row"; SoA is the scattered one there). The layout is a per-workload schema, which is exactly why it belongs in data. Not measured: writes/generation, or Lance's own on-disk columnar behaviour.
Generated by Claude Code