Added the NEON implementation for distance calculation and added the corresponding UT test.

[AmberLZY]

Summary

• This PR introduces ARM NEON optimizations for IP and L2 distance calculations.

Changes

• An ARM NEON-based implementation has been added for IP and L2 distance calculations.

Design Decisions

• The macro is protected, and the macro naming follows the native naming convention, thus having no impact on X86 builds.

Testing

• Unit tests for the NEON implementation of distance calculations have been added.

• Benchmark results show a significant performance improvement on ARM servers.

Notes

• We are happy to work with the maintainers to refine the code structure as needed.

• If this contribution is well received, we have additional optimizations to offer, such as a NEON implementation for FP16 distance calculations and an optimization for ID reordering in the HNSW base library, which can be submitted in subsequent PRs.

[kiplingw]

@AmberLZY, could you let us know roughly what the performance improvement was with the NEON optimization on the platform you tested on?

[AmberLZY]

@AmberLZY, could you let us know roughly what the performance improvement was with the NEON optimization on the platform you tested on?

@kiplingw , this is the performance result we obtained based on our own benchmark on an ARM chip architecture (KUNPENG 920 7280Z).

If you have other benchmarks, we can use them for testing.

[kiplingw]

Just to be clear, the first column is a dataset and the next two columns are what?

[AmberLZY]

Just to be clear, the first column is a dataset and the next two columns are what?

The next two columns indicate the throughput (QPS) of the entire system.

[kiplingw]

Great! Do you have a benchmark for construction as well out of curiosity?

[AmberLZY]

Great! Do you have a benchmark for construction as well out of curiosity?

Yes, we built it ourselves.

[kiplingw]

Can you show us the benchmark for constructing the index with and without the NEON optimization?

[AmberLZY]

Can you show us the benchmark for constructing the index with and without the NEON optimization?

Here is the link to our benchmark:
https://gitcode.com/openeuler/sra_test.git

The NEON optimization can be enabled or disabled based on the -DUSE_NEON option at compile time.

[kiplingw]

Thank you, but I don't have a test bed available. What I was asking is if you could provide benchmark data, like you did in your table above, but specifically on the time improvement to construct the index with the NEON ISA hardware acceleration.

[AmberLZY]

Thank you, but I don't have a test bed available. What I was asking is if you could provide benchmark data, like you did in your table above, but specifically on the time improvement to construct the index with the NEON ISA hardware acceleration.

We did not test improvements in the time taken to construct the index. Our tests focus on the improvement of QPS in the search phase.

[kiplingw]

It would be helpful if you could benchmark construction time since your optimizations, at least on ARM, likely impact it. Search time is important, but construction time is too for some users.

[AmberLZY]

It would be helpful if you could benchmark construction time since your optimizations, at least on ARM, likely impact it. Search time is important, but construction time is too for some users.

Thank you very much for your suggestion! We will consider this for future improvements.

[wjunLu]

Hi @ilyajob05 and @yurymalkov, hope you're both doing well!

We wanted to follow up on this PR, which adds ARM NEON hardware acceleration for IP and L2 distance calculations. We understand you're busy, and we truly appreciate the effort the maintainers have been putting into the project recently.

A quick summary of what this PR brings:

NEON-optimized implementations for both IP and L2 distance, with build-time opt-in via -DUSE_NEON
No impact on x86 builds — the macro guard ensures full backward compatibility
Significant QPS improvement on ARM servers (benchmarked on Kunpeng 920 7280Z, results shared above)
Unit tests covering the NEON code paths
We also noted @kiplingw's suggestion about construction-time benchmarks — we haven't benchmarked that yet, but we're happy to do so if it would help move this forward. And of course, we're open to any code structure feedback or changes you'd like to see before merging.

With the growing adoption of ARM-based servers in HPC and cloud environments, we believe this optimization could benefit a meaningful portion of the community. If there's anything we can do to help review or refine this PR, please let us know.

Thank you again for your time and for maintaining this project!

[ilyajob05]

Hi @ilyajob05 and @yurymalkov, hope you're both doing well!

We wanted to follow up on this PR, which adds ARM NEON hardware acceleration for IP and L2 distance calculations. We understand you're busy, and we truly appreciate the effort the maintainers have been putting into the project recently.
...

Hello @wjunLu , @AmberLZY
One option that's worked well for other Apache-2.0 projects - the contribution lands under the individual author's copyright (i.e., Copyright 2026 ) rather than the corporate one. Apache-2.0 explicitly allows this, and it keeps the code structurally neutral for downstream auditors while fully preserving your authorship and our attribution in the commit history.
If corporate policy requires the company header, we'd want to think a bit more carefully about the path forward

[AmberLZY]

Hi @ilyajob05 and @yurymalkov, hope you're both doing well!
We wanted to follow up on this PR, which adds ARM NEON hardware acceleration for IP and L2 distance calculations. We understand you're busy, and we truly appreciate the effort the maintainers have been putting into the project recently.
...

Hello @wjunLu , @AmberLZY One option that's worked well for other Apache-2.0 projects - the contribution lands under the individual author's copyright (i.e., Copyright 2026 ) rather than the corporate one. Apache-2.0 explicitly allows this, and it keeps the code structurally neutral for downstream auditors while fully preserving your authorship and our attribution in the commit history. If corporate policy requires the company header, we'd want to think a bit more carefully about the path forward

Hello @ilyajob05 , we have removed the company header. If there are any other requirements, please let us know.

[AmberLZY]

Can you show us the benchmark for constructing the index with and without the NEON optimization?

Hello @kiplingw , based on your previous suggestion, we tested the index construction time on the ARM platform, and the comparison results show that NEON optimization can help reduce the index construction time.

[kiplingw]

Good work @AmberLZY. There's improvements in most of your data sets, and it looks like with the best improvements with 16-bit floats.

[wjunLu]

Hi @ilyajob05, thank you so much for your thoughtful feedback on the copyright header — we really appreciate you taking the time to explain the reasoning.

Just wanted to let you know that @AmberLZY has already addressed your concern: the corporate copyright header has been removed from the code. In addition, based on @kiplingw's earlier suggestion, construction-time benchmark results have also been provided, showing measurable improvements on ARM platforms.

We believe the PR is now in good shape and ready for re-review. We genuinely hope this contribution can be merged — ARM NEON optimization is increasingly relevant as ARM-based servers grow in adoption, and we'd love for the broader hnswlib community to benefit from it.

If there's anything else you'd like us to adjust or clarify, we're very happy to do so. Thank you again for your time and for maintaining this wonderful project!