perf(bwt): prefetch the first backward-extension occ blocks after a k-mer lookup - #65
Merged
Conversation
…-mer lookup mb_bwt_smem_batch() already prefetches occ blocks for every in-flight backward and forward extension step, but the stage 2/5 k-mer-cache lookup is a gap: seeding the interval from bwt->pre, and the mb_bwt_set_intv() revert, both leave the occ array untouched, so the first backward extension in stage 3/6 starts on cold blocks. Issue the two prefetches the upcoming step will need -- x[0] and x[0]+size, the addresses mb_bwt_extend() reads for a backward step -- at the end of the lookup stage, so the lines arrive while the entry travels back through the queue. This follows the pattern the four existing prefetch sites already use. Output is unchanged: SAM is byte-identical on 100k HG002 WGS pairs. Mapping-phase wall clock against this commit's parent, c8g.4xlarge (Graviton4, 16 vCPU, gcc 11.5), -t 16, hs38 with ALT contigs, 5 interleaved reps with the build order reversed between reps, per-rep spread 0.29-0.37%: 1kg HG00096 WGS, 5M pairs 41.236s -> 40.832s -1.0% 1kg HG00100 WES, 5M pairs 18.700s -> 18.222s -2.6% The exome gain is the larger of the two, which is what a prefetch fix in the SMEM walk should do: exome spends a bigger share of its time there (~37% of compute self-time versus ~27% for WGS in a sampling profile), so the same per-lookup saving is a bigger fraction of the total.
nh13
added a commit
to nh13/minibwa
that referenced
this pull request
Aug 8, 2026
lh3#65 merged as c42d875, so master carries the occ-block prefetch and merging the feature branch on top is now an empty diff. Per "Removing a feature" the block is deleted rather than marked: the parser rejects `merged`/`superseded` exactly so a graduated block cannot linger and produce a duplicate-application conflict, an optional drop and a nightly issue forever. The weekly reconciler would normally open this deletion itself, but it keys on the PR number in the block and this one recorded `unsubmitted`. The PR was opened from a separate r421-based branch (perf/smem-prefetch-occ) rather than the frozen feature branch, so there was no number here for it to notice going merged. A comment in the manifest records that, since the same split will happen again the next time a feature is offered upstream from a rebased copy. No GRAVEYARD entry: that file is for `[[withdrawn]]` ideas that were investigated and disproven, and this one graduated. Verified on the new base c42d875: 14 features assemble with zero drops, the build still contains both prefetch sites (now from upstream), and the gate passes with 14 covered.
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.
mb_bwt_smem_batch()already prefetches occ blocks for every in-flight backward and forward extension step, but the stage 2/5 k-mer-cache lookup is a gap: seeding the interval frombwt->pre, and themb_bwt_set_intv()revert, both leave the occ array untouched, so the first backward extension in stage 3/6 starts on cold blocks.This issues the two prefetches that step will need —
x[0]andx[0]+size, the addressesmb_bwt_extend()reads for a backward step — at the end of the lookup stage, so the lines arrive while the entry travels back through the queue. It follows the pattern the four existing prefetch sites already use. Six lines, no new helper, no logic change.Output is unchanged — SAM byte-identical on 100k HG002 WGS pairs.
Mapping-phase wall clock, c8g.4xlarge (Graviton4, 16 vCPU, gcc 11.5),
-t 16, hs38 with ALT contigs, 5 interleaved reps with build order reversed between reps, per-rep spread 0.29–0.37%:The exome gain is the larger of the two, which is what a prefetch fix in the SMEM walk should do: exome spends a bigger share of its time there (~37% of compute self-time vs ~27% for WGS in a sampling profile), so the same per-lookup saving is a bigger fraction of the total.