Optimizes reducelanes in diversityCalculation of PQVectors, for Euclidean function

[shyla226]

This pull request introduces improvement to Euclidean similarity function in PQVectors.diversityFunctionFor. From flamegraph, it is observed that considerable amount of time is spent in jdk/incubator/vector/FloatVector.reducelanesTemplate. This is mainly because FloatVector.reducelanes() is expensive and it is being called inside a for loop (via VectorUtil.squareL2Distance). Modification in this pull request moves call to reduceLanes() outside the for loop.

Change proposed here was tested with the benchmark, PQDistanceCalculationBenchmark.diversityCalculation
With this benchmark, ~18% reduction in time was observed when M=64 and ~22% when M=192.

Code modifications:

1. Added a new function pqDiversityEuclidean in VectorUtilSupport and its corresponding implementations
2. Removed for loop in PQVectors.diversityFunctionFor and moved it into pqDiversityEuclidean
3. Moved FloatVector.reducelanes() outside the for loop

Test setup:
Jvector version : main branch (as of 2025-08-28)
JDK version : openjdk version "24.0.2" 2025-07-15
Platform : INTEL(R) XEON(R) PLATINUM 8592+
Benchmark : PQDistanceCalculationBenchmark.diversityCalculation

New changes
I have modified the code to include dot product & cosine functions and implemented similar changes for scoreFunctionFor.
With the changes applied to scoreFunctionFor, when M=64: dot product shows ~30% reduction in latency & cosine shows ~43% reduction.
I can add data points for other subspace counts, if required.

Code modifications:

1. Added new functions pqScoreEuclidean, pqScoreDotProduct, pqScoreCosine in VectorUtilSupport and its corresponding implementations for diversityFunctionFor
2. Added overloaded version of above functions for scoreFunctionFor
3. Removed for loop in PQVectors.diversityFunctionFor and PQVectors.scoreFunctionFor and moved them into respective functions in PanamaVectorUtilSupport
4. Moved FloatVector.reducelanes() outside the for loop
5. Added a new benchmark which uses MutablePQVectors to test this

Test setup:
Jvector version : main branch (as of 2025-10-22)
JDK version : openjdk version "25.0.1" 2025-10-21
Platform : Intel(R) Xeon(R) 6979P
Benchmark : PQDistanceCalculationMutableVectorBenchmark (Added this by replicating PQDistanceCalculationBenchmark to measure performance for MutablePQVectors)

[MarkWolters]

This PR does successfully remove the calls to reduceLanes from the inside of the loop iterating over the subspaces the Euclidean case. I do have a concern about applying this pattern to one specific case but leaving the handling of other cases as is, leaving the code with 2 different implementations for the same problem. Some questions:

1. Why is the optimization only implemented for the Euclidean case? In PanamaVectorUtilSupport, where the call to reduceLanes is made from the squareDistance methods which are called in a loop for the subspace count, likewise reduceLanes is called from the dotProduct methods. Why only fix one?

2. Why is the optimization only applied to diversityFunctionFor(…) and not scoreFunctionFor(…) which uses the same pattern of calling squareL2Distance(…) inside of a loop for each subspace?

[shyla226]

@MarkWolters, thank you very much for the feedback. I can make the changes to dotProduct methods and to function calls in scoreFunctionFor()

[MarkWolters]

@shyla226 please be aware that in order to pass the automated GitHub action regression test any pull request must come from a branch inside the datastax/jvector repository and not a fork of the repository. So while I am willing to review the PR from a fork and provide commentary, in order for it to pass the requirements for merging it will have to be a branch and not a fork.

[shyla226]

@MarkWolters, Sounds good! I will create a branch

[MarkWolters]

@shyla226 I don't think you'll have sufficient permissions to push a new branch to the repository. For now you can keep the changes on a fork and they can be reviewed there while we come up with a solution to this issue.

[shyla226]

@MarkWolters , I have added new functions to include dotproduct & cosine for diversityFunction.
I have also added overloaded function for scoreFunction, for all the 3 cases

[MarkWolters]

Thanks @shyla226, I will review the updated code asap

[shyla226]

Thank you very much @MarkWolters . With the changes, when M=64, dot product shows ~30% reduction in latency & COSINE shows ~43% reduction

[shyla226]

@MarkWolters sorry, accidentally closed it! I will update the test setup used in the description above.

[shyla226]

@MarkWolters, I have addressed the issue with the 2 failed checks and tested the code changes on Windows server

[MarkWolters]

@shyla226 apologies for not addressing this sooner. I have created a branch named reduce_lanes based off of the latest main. Please rebase your change on current main and open a pull request from your fork to the reduce_lanes branch. From the Github UI you should be able to select Contribute --> Open Pull Request and in the resulting screen select the branch you wish to merge to. From there we can run the internal github actions and regression tests and get your changes merged.

[shyla226]

@MarkWolters Thank you very much. I will rebase the changes.

[r-devulap]

First‑pass review: there’s quite a bit of duplicated code, and I think we can consolidate it significantly.

[r-devulap]

This name is a mis-leading, probably better to rename this to pqScoreCosine_preferred?

[r-devulap]

Why do we need this special case? It introduces a lot of duplicated code across all the functions. Wouldn’t the loop below already handle this scenario correctly?

[r-devulap]

We currently have 4 separate implementations (pqScoreEuclidean_64/_128/_256/_512) that are structurally identical aside from the FloatVector.SPECIES_* used. This is a lot of duplicated hot-path code and increases the risk of fixes/optimizations diverging across variants.

Could we fold these into a single generic-ish implementation that takes the species as a parameter, e.g.:

• pqScoreEuclideanImpl(VectorSpecies<Float> species, ...)
• pqScoreEuclidean(...) selects species (SPECIES_PREFERRED, SPECIES_256, SPECIES_128, SPECIES_64) once and dispatches to the shared impl.

This keeps the vectorized logic in one place and avoids the confusing _512 naming given it actually uses SPECIES_PREFERRED on some paths. It should also make it much easier to keep Euclidean/Dot/Cosine implementations consistent.

[r-devulap]

Probably would have been better to comment in #623, apologies for the duplicate review. Ignore the comments here.