Optimize int4 vector computations by avoiding conversions#15742
Merged
kaivalnp merged 4 commits intoapache:mainfrom Feb 26, 2026
Merged
Optimize int4 vector computations by avoiding conversions#15742kaivalnp merged 4 commits intoapache:mainfrom
kaivalnp merged 4 commits intoapache:mainfrom
Conversation
kaivalnp
commented
Feb 20, 2026
Comment on lines
1019
to
1023
| // upper | ||
| ByteVector va8 = unpacked.load(Int4Constants.BYTE_SPECIES, i + j + packed.length()); | ||
| ByteVector diff8 = vb8.and((byte) 0x0F).sub(va8); | ||
| Vector<Short> diff16 = diff8.convertShape(B2S, Int4Constants.SHORT_SPECIES, 0); | ||
| acc0 = acc0.add(diff16.mul(diff16)); | ||
|
|
||
| // lower | ||
| ByteVector vc8 = unpacked.load(Int4Constants.BYTE_SPECIES, i + j); |
Contributor
Author
There was a problem hiding this comment.
Something I found interesting: we see a performance drop after a few warmup iterations if we operate on upper (multiply with self and add to accumulator) before loading lower:
# Warmup Iteration 1: 12.736 ops/us
# Warmup Iteration 2: 16.919 ops/us
# Warmup Iteration 3: 4.171 ops/us
# Warmup Iteration 4: 4.174 ops/us
Iteration 1: 4.179 ops/us
Iteration 2: 4.188 ops/us
Iteration 3: 4.193 ops/us
Iteration 4: 4.201 ops/us
Iteration 5: 4.198 ops/us
Contributor
|
It looks like there are some losses on x86 -- binaryHalfByteDotProductVector sees a small loss, binaryHalfByteSquareVector sees a fairly large loss. I'll investigate a bit. AMD Ryzen AI 395 (AVX 512) Experiment: Mac M2 (128 bit/NEON): Experiment: |
Contributor
|
Re: x86 regression:
|
Contributor
Author
|
Latest JMH benchmarks on AWS Graviton3: ..which is a slight improvement from earlier
Baseline with Candidate with Baseline search-only, use existing index Candidate search-only, use existing index Seems like there's a small improvement with this PR |
Contributor
Author
|
Thanks for the benchmarks + fixes for x86 @mccullocht -- please feel free to push to this branch directly, or I'll try to recreate from your description in a day or so.. |
Contributor
Contributor
Author
|
I ran this JMH benchmark on java --module-path lucene/benchmark-jmh/build/benchmarks --module org.apache.lucene.benchmark.jmh "VectorUtilBenchmark.binaryHalfByte.*Vector" -p size=1024Baseline: There is a drop in performance of Candidate (cherry-pick this PR): The cherry-pick was successful without conflicts, and performance seems to improve in general -- should we target this for 10.5? |
Contributor
Author
|
Thanks @mccullocht could you help with a sanity-check JMH benchmark and |
Contributor
|
x86 benchmarks: VectorUtilBenchmark.binaryHalfByteSquareVector is quite a bit slower, but I also don't know under what conditions we'd actually run this. I suspect we don't do a ton of distance comparisons using two unpacked int4 vectors. |
Contributor
|
1M cohere 1024d vectors, dot_product. Looks like about 5%, roughly the same as on Graviton 3. Targeting 10.5 SGTM. |
mccullocht
approved these changes
Feb 25, 2026
Contributor
Author
This worried me, so I attempted to change it back to operating on shorts (but still avoiding JMH benchmarks on AWS Graviton3 somehow improved further: |
Contributor
Author
|
I got my hands on a temporary Baseline: This PR (latest changes): @mccullocht sorry for another iteration, but could you verify performance on your |
Contributor
|
As of ac60bae lscpu output for completeness |
Contributor
Author
|
Thanks @mccullocht! Looks like performance is equivalent or better in all functions (except small dip in I'll merge + backport this to 10.x in a day or so! |
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.
Spinoff from #15736, where @mccullocht identified vector conversions as a potentially slow area (thanks!).
This PR loads and operates on SIMD registers of the preferred bit size to avoid intermediate conversions.
This was sparked from #15697 where we observed a performance drop in JMH benchmarks of some 4-bit vector computations after initial warmup. It's possible that this issue only affects ARM machines.
Ran JMH benchmarks on an AWS Graviton3 host using:
java --module-path lucene/benchmark-jmh/build/benchmarks --module org.apache.lucene.benchmark.jmh "VectorUtilBenchmark.binaryHalfByte.*Vector" -p size=1024Baseline:
This PR: