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

make IdVal more generic #505

Merged
merged 3 commits into from
Apr 18, 2024
Merged

Conversation

zhengbuqian
Copy link
Collaborator

/kind improvement

Signed-off-by: Buqian Zheng <zhengbuqian@gmail.com>
@sre-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zhengbuqian

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

#include <iostream>

#include "knowhere/file_manager.h"

namespace knowhere {

template <typename I, typename T>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to put this in utils.h but for unknown reason it just won't compile 🧐

}
inline friend bool
operator>(const IdVal<I, T>& lhs, const IdVal<I, T>& rhs) {
return !(lhs < rhs);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

!(lhs < rhs) implies lhs >= rhs, not lhs > rhs

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch!

also added a commit to replace std::pair<float, int64_t> in PrecomputedDistanceIterator with IdVal

@mergify mergify bot added the ci-passed label Apr 16, 2024
Copy link

codecov bot commented Apr 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.36%. Comparing base (3c46f4c) to head (198a91e).
Report is 8 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff            @@
##           main     #505       +/-   ##
=========================================
+ Coverage      0   72.36%   +72.36%     
=========================================
  Files         0       63       +63     
  Lines         0     4291     +4291     
=========================================
+ Hits          0     3105     +3105     
- Misses        0     1186     +1186     

see 63 files with indirect coverage changes

Signed-off-by: Buqian Zheng <zhengbuqian@gmail.com>
@@ -234,7 +236,7 @@ void all_inner_product(
size_t d,
size_t nx,
size_t ny,
std::vector<std::pair<float, int64_t>>& output,
std::vector<knowhere::DistId>& output,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to avoid modifying Faiss in this case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but we have to then choose between:

  • PrecomputedDistanceIterator and bruteforce iterator to still use std::vector<std::pair<float, int64_t>>
  • PrecomputedDistanceIterator to use DistId but its constructor to copy/convert the argument std::vector<std::pair<float, int64_t>> to std::vector<DistId>

also those modified all_* functions and CollectAllResultHandler are not from the original faiss, they are added by us when adding the bruteforce iterator, so it's not that bad.

wdyt?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It adds more pain to me whenever I need to propagate the changes from the Faiss baseline. So, I expect and insist that the changes to the faiss core code to be the last resort.
But it should be acceptable if the functions are not from the original faiss.
Could you please check whether you'll be able to put your change on top of #453 and see whether they are compatible? Just check, don't rebase yet :) Thanks

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tried rebasing a copy of iterator-new-interface onto merge_faiss_changes_from_baseline_v2a and yes they are compatible. The only conflict is CollectAllResultHandler which is easy to fix.

@@ -283,7 +285,7 @@ void all_L2sqr(
size_t d,
size_t nx,
size_t ny,
std::vector<std::pair<float, int64_t>>& output,
std::vector<knowhere::DistId>& output,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@@ -305,7 +307,7 @@ void all_cosine(
size_t d,
size_t nx,
size_t ny,
std::vector<std::pair<float, int64_t>>& output,
std::vector<knowhere::DistId>& output,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

…arator

Signed-off-by: Buqian Zheng <zhengbuqian@gmail.com>
@alexanderguzhva
Copy link
Collaborator

/lgtm

@sre-ci-robot sre-ci-robot merged commit 006beb2 into zilliztech:main Apr 18, 2024
11 checks passed
@zhengbuqian zhengbuqian deleted the update-idval branch April 18, 2024 11:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants