Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize SIMD distance implementation to n-length vectors #20

Open
djc opened this issue Jan 24, 2022 · 3 comments
Open

Generalize SIMD distance implementation to n-length vectors #20

djc opened this issue Jan 24, 2022 · 3 comments

Comments

@djc
Copy link
Owner

djc commented Jan 24, 2022

Our Rust API is currently completely abstract over types that implement the Point trait:

pub trait Point: Clone + Sync {
    fn distance(&self, other: &Self) -> f32;
}

An important part of making instant-distance fast is making the distance() implementation fast, which comes down to using a SIMD implementation. I wrote such an implementation which is specialized for the case of [f32; 300] because that's what we typically use for InstantDomainSearch (since Meta's FastText vectors have 300 elements).

However, for the Python bindings, we have some other needs. There, we don't really have the opportunity to make use of compile-time generics; the vector length should be run-time property of the vector. Since we probably don't want to dereference through a pointer for every vector element access, this also means we might want to change the Hnsw implementations to hold a Vec<f32> instead of a Vec<[f32; 300]> (for example), without losing the performance benefits of avoiding bounds checking where possible. For the Python API, we should then also do a SIMD distance implementation that can adjust to the size of the vector at run-time, ideally without much performance loss compared to the current, fixed-length implementation.

@epoz
Copy link

epoz commented Feb 21, 2023

Do I understand it correctly that the current limitation in the Python binding means you can only use vectors of size 300?
So if we wanted to index some other form of embedding, it will currently not be possible?
(I am considering if it is worth exploring replacing FAISS with instant-distance, but the embedding size of the vectors we use there is 768)

@djc
Copy link
Owner Author

djc commented Feb 21, 2023

Yes, that's right. Should be easy to fork an change it for now, work is ongoing to generally fix this in #35.

@pierd
Copy link

pierd commented Feb 22, 2023

I decided not to mix this with adding new distance metrics. Here's a new PR just for making this work for different vector lengths: #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants