Xxhash: Combiner des hachages de chaînes

Y a-t-il une perte de qualité de hachage si je hache une séquence de chaînes non contiguës à l'aide de XXH64 et que je passe simplement le résultat de chaque hachage comme graine du prochain appel XXH64 ?

Il y a une énorme perte.

Veuillez jeter un œil à l'intérieur de XXH64_state_t , XXH64_update_endian et XXH64_digest_endian .
Vous pouvez voir XXH64 utilise (écrit et lit) les variables membres de XXH64_state_t v1 , v2 , v3 , v4 , total_len pour faire de la valeur de hachage. Et le type de ces valeurs est unsigned long long ( uint_64 , entier 64 bits non signé).

Nous pouvons dire:
(1) Le nombre total de bits de XXH64_state est supérieur à 64 bits.
(2) Si une fois l'état est minimisé (condensé) à une seule valeur de 64 bits, une grande partie des informations disparaît.

Par conséquent, vous ne pouvez pas vous attendre à votre hypothèse. Veuillez envisager d'utiliser les fonctions de streaming .

Comme suggéré par @t-mat, les fonctions de streaming ont en effet été conçues exactement pour ce scénario.

Je suppose que vous êtes concerné par la vitesse.
Je ne pense pas que vous gagneriez quoi que ce soit en passant le résultat d'un hachage à l'autre.
Le maintien d'un contexte de streaming a en effet un coût, mais la finalisation d'un hachage en a aussi. Je m'attends à ce que la finalisation du hachage tous les quelques octets coûte en réalité plus cher que le maintien d'un contexte de streaming, où la finalisation n'est effectuée qu'une seule fois, lorsque XXH_digest() est invoqué.

Mon objectif est de fournir une solution de remplacement pour l'utilisation de CRC32 afin d'améliorer la vitesse, avec un changement de code minimal pour les nombreux sites d'appel. L'approche de streaming n'est techniquement pas applicable, car le hachage d'un flux divisé en morceaux de 10 octets sera le même que le hachage du même flux exactement divisé en morceaux de 100 octets. La « structure » ​​des chaînes non contiguës est pertinente et devrait contribuer au résultat de hachage.

Il s'agit d'une chaîne qui contient des références « indirectes » à d'autres chaînes intégrées à des emplacements arbitraires (un seul niveau de profondeur). J'ai besoin de hacher les chaînes indirectes et les sous-ensembles de la chaîne de base (sans compter les pointeurs vers les chaînes indirectes)

J'ai vu que l'utilisation de XXH64 est plus rapide sur du matériel 64 bits et fonctionnera mieux que XXH32 - en prenant 32 bits du résultat comme hachage.

Je me contente d'un niveau de qualité de hachage de 32 bits, il semblait donc raisonnable de mettre le hachage de 32 bits des différentes chaînes comme germe de l'incorporation de la chaîne suivante.

Si votre structure de programme existante le permet, préférez passer 64 bits entre 2 hachages consécutifs. Effectuez l'extraction 32 bits à la fin uniquement. Cela maximisera la qualité du hachage.

Proposez-vous de modifier le code pour autoriser une graine 64 bits ? Actuellement, plutôt que d'extraire simplement les 32 bits inférieurs pour amorcer l'étape suivante, j'effectue une fusion entre les 32 bits supérieurs et les 32 bits inférieurs afin que tous les 64 bits "contribuent" au report de 32 bits. Malheureusement, il n'est pas possible (sans copier les données) d'ajouter ou de préfixer la valeur intermédiaire de 64 bits à la chaîne suivante, car je n'ai pas le contrôle sur ce stockage, il m'est remis.

Peu importe, je vois maintenant que XXH64 autorise une valeur de départ de 64 bits.