Xxhash: Mettre à jour les comparaisons de vitesse avec crc32

Le problème est,
benchmark a été exécuté sur un Core 2 Duo @ 3GHz.
Ce processeur ne prend pas en charge le matériel crc32c.

De plus, crc32 et crc32c sont des algorithmes similaires mais différents : vous n'obtiendrez pas les mêmes résultats.
crc32 est largement utilisé, crc32c beaucoup moins. Une telle confusion de nom peut induire des problèmes d'interopérabilité non négligeables.

La version crc32 présentée ici est celle fournie dans la suite de tests smasher.
Des versions plus rapides existent, y compris des versions vectorisées.
Il nécessite de modifier la suite de tests pour les intégrer.

Si vous pouvez tolérer la dépendance Intel pour votre application, et pouvez garantir que tous vos processeurs clients sont assez récents (ce qui est raisonnable en 2016), vous pouvez alors utiliser le matériel crc32c, c'est en effet très rapide.

xxHash a été créé dans un contexte différent, utilisant un processeur sans cette capacité, et avec l'objectif d'une portabilité maximale, bien au-delà du domaine d'Intel (bras, mips, puissance, etc.). Par conséquent, aucune dépendance sur les fonctionnalités spécifiques à la marque.

@Cyan4973
En guise de suivi très tardif, pourriez-vous fournir des informations sur le nouveau XXH3 par rapport au crc32c ?

Le matériel crc32c en soi n'est pas compétitif. Bien qu'il soit certainement plus rapide que le logiciel crc32, il ne peut pas suivre ILP, que la plupart des algorithmes de hachage modernes utilisent.

Cependant, plusieurs canaux crc32c en parallèle peuvent être plus efficaces. Dans ce cas, le résultat exact dépend de la mise en œuvre. De nombreuses implémentations peuvent être trouvées sur Internet. J'ai trouvé plusieurs implémentations qui peuvent XXH64 vitesse de XXH3 . C'est peut-être une question de chercher plus.

CRC32 et CRC32C peuvent être implémentés très efficacement à l'aide des instructions pclmulqdq ou ARMv8 CLMUL d'Intel.

Il y a quelque temps, j'ai rassemblé quelques implémentations ARM à l'aide d'instructions CRC32 et CLMUL et leurs vitesses oscillent autour de 4,1 Go/s sur rk3399. Maintenant, je les ai comparés avec xxh32 et xxh64 et j'ai obtenu respectivement 3,5 Go/s et 2,5 Go/s.

Est-il prévu que xxh64 soit plus lent que xxh32 sur ARMv8, ou quelque chose ne va pas ?

On s'attend à ce que xxh64 soit plus lent que xxh32 sur les binaires 32 bits.
Sur les binaires 64 bits, c'est moins probable, mais on peut toujours imaginer une puce qui comporte des instructions de multiplication 64 bits faibles/lentes, beaucoup plus lentes que les 32 bits, auquel cas c'est possible.
Malheureusement, la famille de puces ARMv8 est assez vaste et chaque puce peut présenter des compromis de performances très différents. Je dirais donc que ce cas doit se produire quelque part, mais je n'en ferais pas la règle.

Pour un hachage 64 bits plus rapide sur ARM, vous pouvez être intéressé par le nouveau XXH3_64bit() , présenté dans la dernière version.

Merci!
Les binaires sont en 64 bits.
XXH3_64bit certainement mieux. Sans utiliser la vectorisation NEON, j'obtiens 3,9 Go/s et avec NEON près de 4,0 Go/s. Cependant, CRC32 utilisant vmull_p64 a un débit légèrement meilleur.