perf(index): vectorized merge kernels and frequency-bound pruning for FTS conjunctions#7625
Draft
BubbleCal wants to merge 1 commit into
Draft
Conversation
Contributor
|
ACTION NEEDED The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification. For details on the error please inspect the "PR Title Check" action. |
…r bulk fts conjunctions Three changes to the bulk AND/phrase candidate pipeline, all score-identical to the classic loop: - Clause-count-specialized merge kernels (2 and 3 clauses) keep cursors and bounds in registers, with an AVX2 find_next_geq catch-up scan (the analogue of Lucene's VectorUtil.findNextGEQ) replacing the mispredict- heavy scalar walk. Generic kernel covers other widths. - Two-pass batched scoring: kernels only record (doc, offsets) matches; doc lengths are then gathered back-to-back so their cache misses overlap, and the prune/score/insert pass runs in doc order with the classic semantics. - A per-clause frequency-bucketed score-bound LUT lets kernels skip lead docs before any follower advance when even the doc-length-free bound cannot beat the threshold (score-first ordering, Lucene-style); the bound is monotone so the skipped set is a subset of the exact prune. Warm mmlb AND @200M, 8 concurrent: k10 0.060->0.049s (161qps), k100 0.118->0.098s (81qps); phrase\@50m 3w k10 0.210->0.204s, 2w 0.042->0.040s. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
BubbleCal
force-pushed
the
yang/lan2-88-fts-simd-merge-kernels
branch
from
2f9de34 to
3c60d9a
Compare
BubbleCal
force-pushed
the
yang/lan2-88-fts-bulk-conjunction
branch
from
fc1af4b to
22e3522
Compare
This was referenced Jul 4, 2026
BubbleCal
changed the title
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
1 participant
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.
Stacked on #7624.
What
Two refinements of the bulk conjunction merge introduced in #7624, both result-identical:
find_next_geq(branchless 8-wide compare + movemask, the analogue of Lucene'sVectorUtil.findNextGEQ) instead of the mispredict-heavy scalar walk. Runtime-dispatched with a scalar fallback;#[target_feature(enable = "avx2")]covers the whole kernel so the vector scan inlines.Measured vs #7624 (its base)
Per-branch-tip wheels, 1000 queries × 8 concurrent. AND on the 200M-doc
v3-256 index (warm, prewarmed); phrase on the 50M-doc v3-256 positions
index (steady-state passes 3-4 of 4, no prewarm):
Profile: the scalar catch-up was 41.5% of the AND profile at ~6ns/element (branch mispredicts on irregular doc gaps); the AVX2 kernels cut it to 32.7% and falling.
Verification
cargo test -p lance-index,clippy -D warnings,fmt --checkclean.🤖 Generated with Claude Code