Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[FEATURE]: Add `perfect_hashing` probing scheme

Ouverte
  • Quelque chose ne va pas ?
#487 2 commentaires 1 réaction 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@njones93531 y travaille déjà.

Depuis le 3/6/2024.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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
Langage dominant
Cuda
Étoiles
674
Forks
123
Merge moyen
1 j 13 h
PR mergées (30 j)
8

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/cuCollections

Toutes les issues de NVIDIA/cuCollections

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.