Xxhash: Ajouter du hachage Meow dans les benchmarks

meow_hash dépend entièrement de la présence d'instructions AES à accélération matérielle.

Je soupçonne qu'il ne sera même pas compilé en l'absence de ces instructions, car le code est assez court et je ne vois aucun chemin de code de sauvegarde de logiciel. En outre, toutes les instructions AES que j'ai pu lire utilisent directement Intel intrinsèque, elles ne sont donc pas portables dans toutes les architectures, quelles que soient les capacités matérielles.

Ce n'est pas nécessairement une "mauvaise" chose : après tout, ils obtiennent une grande vitesse pour une longue entrée en retour.

Mais le point principal est qu'en s'appuyant sur un tel jeu d'instructions matérielles spécialisées, la portabilité est hors de la liste des fonctionnalités.

Comme effet secondaire, il ne fonctionnerait même pas sur la plate-forme utilisée pour les benchmarks xxHash.

Peut-être que je devrais passer un peu de temps à documenter cela.

Ce n'est plus vrai, vous devriez revoir cela.

Oui, en lisant les annonces, miaou s'est beaucoup amélioré en quelques révisions.
Il annonce même la compatibilité avec ARM.

J'aurai besoin d'un peu de temps pour l'approfondir.

Je viens de jeter un coup d'œil rapide et je n'ai pas pu trouver de chemin de sauvegarde du logiciel. Peut-être qu'il est là et je l'ai juste raté.
De plus, je ne sais pas encore si différents modules matériels AES sont garantis pour produire exactement la même valeur de hachage, ou s'il y en a plus (comme des paramètres supplémentaires qui peuvent être prédéfinis différemment et nécessitent des instructions spécifiques à la machine pour être uniformes). C'est une chose de calculer et de consommer le hachage localement, auquel cas la représentation exacte n'a pas d'importance. C'en est une autre d'écrire/sérialiser la valeur et de s'attendre à ce qu'elle soit lue/reproduite exactement sur n'importe quel autre système. Cette partie de l'interopérabilité est un peu plus délicate.
Mais encore une fois, c'est peut-être là, et j'ai juste besoin de temps pour l'examiner.

Pour la référence, c'est contre ma dernière version, 2.0 GHz Core i7 Gen 2 (Sandy Bridge)

Clang 7.0.1
Drapeaux : -O3 -march=native

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54765 it/s ( 5348.2 MB/s)
XXH32 unaligned     :     102400 ->    53782 it/s ( 5252.1 MB/s)
XXH64               :     102400 ->   104882 it/s (10242.4 MB/s)
XXH64 unaligned     :     102400 ->   105935 it/s (10345.2 MB/s)
XXH32a              :     102400 ->    78027 it/s ( 7619.8 MB/s)
XXH32a unaligned    :     102400 ->    75624 it/s ( 7385.2 MB/s)
XXH64a              :     102400 ->    77204 it/s ( 7539.5 MB/s)
XXH64a unaligned    :     102400 ->    76209 it/s ( 7442.3 MB/s)
XXH auto            :     102400 ->   105179 it/s (10271.4 MB/s)
XXH auto unaligned  :     102400 ->   101546 it/s ( 9916.6 MB/s)
XXH32 auto          :     102400 ->   107646 it/s (10512.3 MB/s)
XXH32 auto unaligne :     102400 ->   104364 it/s (10191.8 MB/s)
XXH64 auto          :     102400 ->   107443 it/s (10492.4 MB/s)
XXH64 auto unaligne :     102400 ->   105843 it/s (10336.3 MB/s)
meow auto           :     102400 ->   214435 it/s (20940.9 MB/s)
meow auto unaligned :     102400 ->   213289 it/s (20829.0 MB/s)

Avec -march=penryn -mno-sse4.2 -mno-avx et l'implémentation C :

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54106 it/s ( 5283.8 MB/s)
XXH32 unaligned     :     102400 ->    53303 it/s ( 5205.4 MB/s)
XXH64               :     102400 ->   107245 it/s (10473.1 MB/s)
XXH64 unaligned     :     102400 ->   107774 it/s (10524.8 MB/s)
XXH32a              :     102400 ->    78394 it/s ( 7655.6 MB/s)
XXH32a unaligned    :     102400 ->    79666 it/s ( 7779.9 MB/s)
XXH64a              :     102400 ->    78907 it/s ( 7705.7 MB/s)
XXH64a unaligned    :     102400 ->    78179 it/s ( 7634.6 MB/s)
XXH auto            :     102400 ->   108878 it/s (10632.6 MB/s)
XXH auto unaligned  :     102400 ->   105124 it/s (10266.0 MB/s)
XXH32 auto          :     102400 ->   105819 it/s (10333.9 MB/s)
XXH32 auto unaligne :     102400 ->   103970 it/s (10153.3 MB/s)
XXH64 auto          :     102400 ->   110021 it/s (10744.2 MB/s)
XXH64 auto unaligne :     102400 ->   107109 it/s (10459.9 MB/s)
meow auto           :     102400 ->    15962 it/s ( 1558.8 MB/s)
meow auto unaligned :     102400 ->    16022 it/s ( 1564.6 MB/s)

Ce n'est plus vrai, vous devriez revoir cela

...aa et dans Meow 0.5 c'est encore vrai ; dans la dernière version, ils n'ont à nouveau que le chemin de code x64 AES :)

Alors oui, Meow Hash est un peu spécifique à x86_64 et Nehalem+, ou il doit passer à une version de secours lente.

Pendant ce temps, XXH3 a vectorisé les chemins de code pour tous les x86_64 (y compris Core 2 et amis), Pentium 4+ (qui est requis pour Windows 7+), ARMv7-A w/NEON (disponible sur la plupart des appareils Android et tous les appareils iOS à l'exception de l'iPhone d'origine ), ARM64 (tous les iPhones et Android récents), VSX POWER9 (de nombreux serveurs et supercalculateurs en ont, mais c'est un marché de niche), et si cela ne suffisait pas, même la version scalaire est toujours très rapide même sur 32 bits cibles, étant donné qu'elles ont un multiplicateur décent.

Je commence à recueillir d'autres résultats de référence, car il y a eu plusieurs demandes de ce genre au fil des ans.
A commencer par celui-ci, qui a été une demande récurrente.

meowHash est en effet très rapide, marquant approximativement la même vitesse que XXH3 pour les données volumineuses (~100 Ko), donc un peu plus rapide que XXH128 .
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

Cela étant dit, meowHash est vraiment conçu pour les données volumineuses. Concernant les _small_ data, les performances ne sont pas comparables, car l'algorithme nécessite un gros coût fixe, mal amorti sur les petites données.

Un développement inquiétant est qu'il y a une divergence dans "la façon de représenter et d'interpréter les résultats".
Pour les grosses données, c'est assez simple, un tableau trié peut suffire, donnant une idée instantanée du classement.
Pour les petites données cependant, cela semble plus complexe.
Jusqu'à présent, j'ai utilisé des graphiques, fournissant un résultat de vitesse par longueur et scénario différents. En raison de la présentation de _plus_ d'informations, il est nécessairement plus difficile à interpréter.

En conséquence, il n'est pas clair si un lecteur, après avoir trouvé le premier chiffre de performance dans le tableau du haut, prendra la peine de rechercher ci-dessous des graphiques supplémentaires, guidant ainsi son choix tout en manquant potentiellement une information importante pour son cas d'utilisation.

Un autre problème concerne les graphiques eux-mêmes. Une table triée peut être étendue, relativement facilement. Il y a des limites, bien sûr, mais de manière générale, ajouter un concurrent n'ajoute qu'une ligne.
Cependant, dans un graphique, chaque concurrent est représenté par une ligne. Les lignes ont tendance à se chevaucher. Il n'y a qu'un nombre limité de couleurs à choisir, etc. Très rapidement, si le nombre de prétendants représentés est grand, c'est juste un gros bordel.
Ainsi, si les performances de petites données nécessitent un graphique, cela limite considérablement le nombre de concurrents pouvant être représentés.

L'ajout d'un paragraphe contenant des données de référence « brutes », bien que louable, est un mauvais substitut.

Par conséquent, j'envisageais de « résumé » le résultat du test de petites données et de créer un « nombre de performances » qui peut être utilisé dans un tableau classé, pour donner au moins un aperçu des performances générales sur les petites données. Les lecteurs intéressés devraient toujours chercher des informations plus précises (graphiques), mais au moins, l'idée que certains algorithmes sont plus adaptés aux petites données que d'autres peut être véhiculée de manière relativement simple.

Il reste le problème que les graphiques ne peuvent représenter qu'un nombre limité de candidats, et peut-être que celui qu'un lecteur souhaite observer ne fait pas partie de la liste sélectionnée (même lorsque des données brutes sont disponibles).

Je me demandais s'il y aurait une meilleure façon de représenter des graphiques. Quelque chose de plus dynamique qu'une capture d'écran préparée, permettant à un utilisateur de sélectionner les candidats qui doivent être visibles.

hachage meow ajouté en comparaison :
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

L'ajout d'une entrée à la table est très bien.
Mais j'ai encore besoin d'une meilleure façon de dessiner des graphiques pour un grand nombre de candidats.