Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[BUG] CAGRA multi-CTA and multi-kernel search over-allocate the hashmap they use

未关闭 适合新手
#2,856 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
70/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
cpp

调研方向

从 cpp/src/neighbors/detail/cagra/search_plan.cuh 中的 calc_hashmap_params 开始,这里以字节为单位计算哈希表大小。将它与 search_single_cta.cuh(约第 209-210 行)中的单 CTA 计划进行比较,后者在调整大小前把字节数转换为元素数量。然后检查 search_multi_cta.cuh(约第 188 行)和 search_multi_kernel.cuh(约第 371 行)中对应的 resize 调用。完成标准是两条路径都传递元素数量,并确认分配规模会缩小。复现脚本尚未运行,因此在编辑前先确认大小。

由索引模型根据 Issue 内容生成。

描述

bug

Describe the bug

search_plan_impl::calc_hashmap_params stores the size of the global hashmap in bytes (search_plan.cuh#L375):

hashmap_size = sizeof(INDEX_T) * max_queries * hashmap::get_size(hash_bitlen);

hashmap is a lightweight_uvector<INDEX_T> (#L157), whose resize takes an element count and allocates new_size * sizeof(T) bytes from the workspace resource (#L62-L68). The single-CTA plan converts the size to an element count before resizing (search_single_cta.cuh#L209-L210). The multi-CTA and multi-kernel plans pass the byte count as if it were element count:

So both allocate 4x the table for uint32_t indices.
3/4 of each allocation is never touched.

Expected behavior

All functions should use the right units

主要语言
Cuda
星标
869
派生
243
平均合并
3 天 17 小时
30 天内合并 PR
88

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

NVIDIA/cuvs 的其他 Issue

查看 NVIDIA/cuvs 的全部 Issue

相似的 Issue

更多 Performance Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。