Initial implementation of SVS Runtime package

[rfsaliev]

No description provided.

[ethanglaser]

I notice when svs::svs_compile_options is not included, performance decreases. I tried it because we do not link it in https://github.com/RedisAI/VectorSimilarity/blob/main/src/VecSim/CMakeLists.txt#L47-L52 - should we?

[mihaic]

I will try it and check VecSim performance.

[ethanglaser]

What is svs_devel? Is there a reason linking here would be different than lines 131-135?

[ahuber21]

Some minor comments. Let's discuss how to tackle todos.

[ahuber21]

I suggest to sort all headers in the order

1. "Local" headers (includes with quotes, same directory)
2. SVS runtime headers
3. SVS core headers
4. deps headers
5. std library, other core headers

Also, in svs/include we use mainly quote includes. IMO we should stay consistent here. Or are there reasons against?

[ahuber21]

Is padding with -1 specific to Faiss? Would it make sense to accept a parameter to pick a different value for padding? Maybe even skip this entirely?

[rfsaliev]

Good question.
The search() method should somehow 'return' the actual number of results - for example, if k > index.size().
Possible solutions:

1. Pad result buffers with special values: label = max_size_t, distance = infinity
2. One more argument - pointer to a vector of size_t where to store numbers
3. Use ResultsAllocator

[rfsaliev]

PS. I would vote for the option 3. - it will make search signatures consitent.

[rfsaliev]

@ahuber21, can you please respond?
Thank you.

[ahuber21]

Sorry for not replying. Good point about consistency. In its current form, is ResultsAllocator already capable of initializing to arbitrary values?
In other words, can we have a special allocator for Faiss that initializes with inf distance and -1 index?

Would the initialization happen on allocation, or would it only backfill between [found, k-1]? Given that search is typically an expensive operation, I wouldn't expect a big impact from initializing everything first..

[mihaic]

I think we should not set prefetching defaults in the runtime and instead let libsvs set the defaults (currently using estimate_prefetch_parameters).

[rfsaliev]

• According to the request, VamanaIndex::SearchParams contains prefetch parameters.
• Prefetching values =0 interpreted as "use default" in make_search_parameters()

[rfsaliev]

@mihaic, can you please explain in details which behavior is expected there:

1. Should we let user disable prefetching?
2. Should we let MutableVamanaIndex to select all search parameters including window size itself?
3. BuildParameters: which values should be default?

Thank you.

[mihaic]

Behavior 2 is expected here and, as discussed, for any other parameters that are not required by libsvs. I am restating the behavior to hopefully clarify: Any optional libsvs parameter should have a default value in libsvs_runtime that means "let libsvs choose". libsvs_runtime should still allow all possible values for libsvs parameters (e.g., disabling prefetching).

Edit: I realized I misinterpreted the numbering in your question. Hopefully my answer still covers everything.

[ethanglaser]

This is no longer aligned with https://github.com/ahuber21/faiss/blob/svs-io/faiss/svs/IndexSVSFaissUtils.h#L109 which leads to the build fail in CI - I guess we should revise that line in FAISS? Or revert this back to int64_t?

[rfsaliev]

@ahuber21, is it possible to reuse SVS_BUILD_TESTS here?

[ahuber21]

Good point. I'll try to consolidate.

[ahuber21]

It's not really possible in the current setup because runtime lib is built separate from our main repo.