Xxhash: Füge Meow-Hash zu den Benchmarks hinzu

meow_hash hängt vollständig vom Vorhandensein von hardwarebeschleunigten AES-Befehlen ab.

Ich vermute, dass es ohne diese Anweisungen nicht einmal kompiliert werden kann, da der Code ziemlich kurz ist und ich keinen Software-Backup-Codepfad sehe. Außerdem verwenden alle AES-Anweisungen, die ich lesen konnte, direktes Intel-Intrinsic, sodass es unabhängig von den Hardwarefunktionen nicht über die Architektur hinweg portiert werden kann.

Es ist nicht unbedingt eine "schlechte" Sache: Schließlich erhalten sie im Gegenzug eine hohe Geschwindigkeit für lange Eingaben.

Aber der wichtigste Punkt ist: Wenn man sich auf einen solchen spezialisierten Hardware-Befehlssatz verlässt, ist die Portabilität aus der Funktionsliste gestrichen.

Als Nebeneffekt würde es nicht einmal auf der Plattform laufen, die für xxHash-Benchmarks verwendet wird.

Vielleicht sollte ich etwas Zeit damit verbringen, das zu dokumentieren.

Dies ist nicht mehr wahr, Sie sollten dies erneut überprüfen.

Ja, beim Lesen der Ankündigungen hat sich Miau in ein paar Überarbeitungen stark verbessert.
Es kündigt sogar die Kompatibilität mit ARM an.

Ich brauche etwas Zeit, um mir das genauer anzusehen.

Ich habe nur oberflächlich nachgesehen und konnte keinen Software-Backup-Pfad finden. Vielleicht ist es da und ich habe es einfach übersehen.
Außerdem weiß ich noch nicht, ob verschiedene AES-Hardwaremodule garantiert genau den gleichen Hash-Wert produzieren oder ob es mehr gibt (wie zusätzliche Parameter, die möglicherweise anders voreingestellt sind und maschinenspezifische Anweisungen benötigen, um einheitlich zu sein). Es ist eine Sache, Hash lokal zu berechnen und zu konsumieren, in diesem Fall spielt die genaue Darstellung keine Rolle. Es ist eine andere, den Wert zu schreiben/serialisieren und zu erwarten, dass er auf jedem anderen System genau gelesen/reproduziert wird. Dieser Teil der Interoperabilität ist etwas kniffliger.
Aber vielleicht ist es noch einmal da, und ich brauche nur etwas Zeit, um es mir anzusehen.

Als Referenz ist dies gegen meine neueste Version, 2,0 GHz Core i7 Gen 2 (Sandy Bridge).

Klang 7.0.1
Flaggen: -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)

Mit -march=penryn -mno-sse4.2 -mno-avx und der C-Implementierung:

./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)

Dies ist nicht mehr wahr, Sie sollten dies noch einmal überprüfen

...aaund in Meow 0.5 ist es wieder wahr; in der neuesten Version haben sie wieder nur den x64-AES-Codepfad :)

Also ja, Meow Hash ist irgendwie spezifisch für x86_64 und Nehalem+, oder es muss auf eine langsame af-Fallback-Version umgestellt werden.

Inzwischen hat XXH3 vektorisierte Codepfade für alle x86_64 (einschließlich Core 2 und Freunde), Pentium 4+ (erforderlich für Windows 7+), ARMv7-A w/NEON (verfügbar auf den meisten Androids und allen iOS-Geräten außer dem Original-iPhone ), ARM64 (alle neueren iPhones und Androids), VSX POWER9 (viele Server und Supercomputer haben diese, aber es ist ein Nischenmarkt), und als ob das nicht genug wäre, ist selbst die Skalarversion auch auf 32-Bit immer noch sehr schnell Ziele, vorausgesetzt, sie haben einen anständigen Multiplikator.

Ich fange an, weitere Benchmark-Ergebnisse zu sammeln, da es im Laufe der Jahre mehrere Anfragen dieser Art gab.
Beginnend mit dieser, die eine wiederkehrende Anfrage war.

meowHash ist in der Tat sehr schnell und erreicht ungefähr die gleiche Geschwindigkeit wie XXH3 für große Daten (~100 KB), also etwas schneller als XXH128 .
https://github.com/Cyan4973/xxHash/wiki/Leistungsvergleich

Davon abgesehen ist meowHash wirklich für große Datenmengen konzipiert. Bei _kleinen_ Daten ist die Leistung nicht vergleichbar, da der Algorithmus hohe Fixkosten erfordert, die sich bei kleinen Daten schlecht amortisieren.

Eine besorgniserregende Entwicklung ist, dass es eine Diskrepanz in der "Repräsentation und Interpretation von Ergebnissen" gibt.
Bei großen Datenmengen ist es ziemlich einfach, eine sortierte Tabelle kann ausreichen, um eine sofortige Vorstellung von der Rangfolge zu erhalten.
Für kleine Daten scheint es jedoch komplexer zu sein.
Bisher habe ich Diagramme verwendet, die ein Geschwindigkeitsergebnis für verschiedene Längen und Szenarien liefern. Durch die Angabe von _mehr_ Informationen ist es notwendigerweise schwieriger zu interpretieren.

Infolgedessen ist es unklar, ob ein Leser, nachdem er die erste Leistungszahl in der prominenten oberen Tabelle gefunden hat, unten nach zusätzlichen Grafiken sucht und so seine Wahl leitet, während er möglicherweise eine wichtige Information für seinen Anwendungsfall übersieht.

Ein weiteres Problem sind die Grafiken selbst. Eine sortierte Tabelle kann relativ einfach erweitert werden. Es gibt zwar Grenzen, aber im Allgemeinen fügt das Hinzufügen eines Konkurrenten nur eine Zeile hinzu.
In einem Diagramm wird jedoch jeder Anwärter durch eine Linie dargestellt. Linien neigen dazu, sich zu überlappen. Es gibt nur so viele Farben zur Auswahl usw. Sehr schnell, wenn die Anzahl der vertretenen Konkurrenten groß ist, ist es nur ein großes Durcheinander.
Wenn also eine kleine Datenleistung eine Grafik erfordert, schränkt dies die Anzahl der darstellbaren Konkurrenten stark ein.

Das Hinzufügen eines Absatzes mit "rohen" Benchmark-Daten ist zwar lobenswert, aber ein schlechter Ersatz.

Daher überlegte ich, das Ergebnis des Tests mit kleinen Daten "zusammenzufassen" und eine "Leistungszahl" zu erstellen, die in einer Rangtabelle verwendet werden kann, um zumindest einen Hinweis auf die allgemeine Leistung bei kleinen Daten zu geben. Nach genaueren Informationen (Graphen) müssten interessierte Leser zwar noch nach unten schauen, aber zumindest lässt sich die Vorstellung, dass manche Algorithmen eher für kleine Daten geeignet sind als andere, auf relativ einfache Weise vermitteln.

Es gibt immer noch das Problem, dass Grafiken nur eine begrenzte Anzahl von Konkurrenten darstellen können und möglicherweise diejenige, die ein Leser beobachten möchte, nicht Teil der ausgewählten Liste ist (auch wenn Rohdaten verfügbar sind).

Ich habe mich gefragt, ob es eine bessere Möglichkeit geben würde, Grafiken darzustellen. Etwas Dynamischeres als ein vorbereiteter Screenshot, der es einem Benutzer ermöglicht, auszuwählen, welche Konkurrenten sichtbar sein sollen.

miau hash im vergleich hinzugefügt:
https://github.com/Cyan4973/xxHash/wiki/Leistungsvergleich

Das Hinzufügen eines Eintrags zur Tabelle ist in Ordnung.
Aber ich brauche noch einen besseren Weg, um Grafiken für eine große Anzahl von Kandidaten zu zeichnen.