Clarification on the Distance Kernels used by Knowhere when using HNSW Index (Especially on ARM)

[ThatikondV]

Hi,

From my understanding, Knowhere internally calls into HNSWlib for HNSW index construction and search. I have a question regarding which kernel implementations are actually used during this flow.

My questions:

1. When Knowhere uses HNSW for indexing/search, are the distance computations (L2 / IP) executed by: 1. Knowhere’s own optimized vector kernels (e.g., SVE/NEON in distances_*), 2. or the scalar functions from HNSWlib’s space_l2.h and space_ip.h?

2. If Knowhere’s optimized kernels (e.g., SVE) are not reused in the HNSW integration, is there any plan to unify or bridge the distance computation layer between Knowhere and HNSW, so that ARM-optimized paths can be reused across both?

[foxspy]

For question 1, distance computations are all handled through Knowhere’s own optimized vector kernels (see src/simd), and the selection is dynamically determined at runtime based on runtime platform (see src/simd/hook.cc) . However, it should be noted that the current default HNSW implementation in Knowhere uses faiss_hnsw instead of hnswlib.

For question 2, the current computational operators are already unified to use Knowhere’s implementation.

If you find any inconsistencies with the above conclusions, please provide more context.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Rotten issues close after 30d of inactivity. Reopen the issue with /reopen.