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
Promote filtering_rate to base search_params; honor it in brute_force
`filtering_rate` (a hint of the fraction of items filtered out by the
sample filter) previously lived on `cagra::search_params` only. CAGRA
used it to size `itopk_size` and, when the user left it at its default
of `-1.0`, called `bitset_view::count(res)` on every search — a GPU
popcount reduction + host sync that adds measurable latency.
`brute_force` filtered search also called `bitset_view::count(res)` on
every search to compute `sparsity` (used to choose between the dense
tiled GEMM path and the sparse CSR path), but had no user-facing knob
to skip the auto-detection.
This change:
- Moves `float filtering_rate = -1.0` from `cagra::search_params` to
the base `cuvs::neighbors::search_params`. `cagra::search_params`
inherits it; existing code that accesses `params.filtering_rate`
is unaffected.
- Plumbs `brute_force::search_params` through `detail::search` and
`brute_force_search_filtered`. When `params.filtering_rate >= 0`,
the hint is used directly as `sparsity` and the per-search popcount
is skipped on the dense path. The CSR path still needs an exact
non-zero count to size the matrix, so popcount runs lazily there.
- Algorithms that don't use the hint (`ivf_flat`, `ivf_pq`, `hnsw`)
ignore the new base field; their `search_params` inherit it but
nothing reads it.
Tests: extends `brute_force_prefiltered.cu` with
`ResultWithFilteringRateHint` cases for both bitmap and bitset
fixtures (float and half), reusing the existing parameter matrix and
asserting that results match the auto-detect path.
Closes#1960.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments