You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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)
Our Rust API is currently completely abstract over types that implement the
Point
trait: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 aVec<f32>
instead of aVec<[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.The text was updated successfully, but these errors were encountered: