Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[FEATURE]: Add `perfect_hashing` probing scheme

オープン
  • 何か問題がありますか？
#487 コメント 2 件 リアクション 1 件 担当者 1 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@njones93531 がすでに取り組んでいます。

2024年6月3日 から。

評価

この issue はまだ評価されていません。

説明

good first issue P2: Nice to have type: feature request
Is your feature request related to a problem? Please describe.

Perfect hash functions describe an injective mapping from the input key domain into the hash map's slot index domain. In other words, Each distinct key hashes to a distinct slot in the map.

This setup allows for a set of optimizations:

  • Perfect hash functions don't require any probing logic, since there can't be any colliding key in a slot that is not equal to the probe key
  • The injectivity constraint guarantees that any index value produced by the hash function is smaller than the map's capacity. Thus, we can get rid of the remainder computation.
  • Key equality comparison can be simplified, i.e., we only have to check if the key in the slot is equal to a sentinel or not.
Describe the solution you'd like

Add a new class cuco::perfect_hashing<class Hash> to our probing scheme zoo which behaves as follows:

When the dereferencing operator of the probing iterator is called for the first time (at the initial probing position), return slots + hash(key). After incrementing the iterator, always return end(), meaning that there is at most one probing step.

A user must ensure that the Hash function in combination with the input key set actually forms a perfect hash function, and the maximum hash values is smaller than the map's capacity. Otherwise behavior is undefined.

Notes on the implementation:

  • Currently each of our probing schemes uses the same probing_iterator class. This new probing scheme doesn't fit into the logic of the existing iterator. Thus I propose to let each probing scheme define its own probing_iterator as a member class.
  • Since perfect hashing only requires bitwise comparison against the sentinel, we ignore any user-specified KeyEqual operator.
Describe alternatives you've considered

There is one more optimization we could additionally apply, but I would vote against it due to technical reasons:

Perfect hashing guarantees that there are no collisions. Thus, we could insert keys using non-atomic STG instructions, which has proven to be significantly faster compared to atomic CAS operations.
This however leads to some undesireful side effects due to the relaxed memory ordering of the GPU, which ultimately leads to implausible return values from some of our APIs (insert_and_find and also bulk insert; see example in the bottom paragraph of https://github.com/NVIDIA/cuCollections/issues/475#issuecomment-2113437463).

If this optimization is desired, it can still be enabled by specifying cuda::thread_scope_thread when instantiating the map type. This is a bit hacky but I think it's better than breaking the existing logic, introducing spurious errors in the aforementioned return values.

Additional context

See discussion #475

### Tasks
主要言語
Cuda
スター
671
フォーク
122
平均マージ
4日 19時間
マージ済み PR（30日）
10

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA/cuCollections のほかの issue

NVIDIA/cuCollections の issue をすべて見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。