[FEATURE]: Add `perfect_hashing` probing scheme

Offen
  • Stimmt etwas nicht?
#487 2 Kommentare 1 Reaktion 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@njones93531 arbeitet bereits daran.

Seit 03.6.2024.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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
Vorherrschende Sprache
Cuda
Sterne
674
Forks
123
Ø Merge
19 Std. 7 Min.
Gemergte PRs (30 T.)
10

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NVIDIA/cuCollections

Alle Issues in NVIDIA/cuCollections

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.