Xxhash: Geschwindigkeitsvergleiche mit crc32 aktualisieren

Das Problem ist,
Benchmark wurde auf einem Core 2 Duo @3GHz ausgeführt.
Diese CPU unterstützt keine Hardware crc32c.

Außerdem sind crc32 und crc32c ähnliche, aber unterschiedliche Algorithmen: Sie erhalten nicht die gleichen Ergebnisse.
crc32 ist weit verbreitet, crc32c viel weniger. Eine solche Benennungsverwirrung kann zu nicht trivialen Interoperabilitätsproblemen führen.

Die hier verwendete crc32-Version ist diejenige, die in der Smasher-Testsuite bereitgestellt wird.
Es gibt schnellere Versionen, einschließlich vektorisierter.
Es erfordert, die Testsuite zu ändern, um sie zu integrieren.

Wenn Sie die Abhängigkeit von Intel für Ihre Anwendung tolerieren können und sicherstellen können, dass alle Ihre Client-CPUs aktuell genug sind (was 2016 angemessen ist), können Sie Hardware crc32c verwenden, was in der Tat sehr schnell ist.

xxHash wurde in einem anderen Kontext erstellt, mit einer CPU ohne diese Fähigkeit und mit dem beabsichtigten Ziel einer maximalen Portabilität, weit über Intels Bereich hinaus (Arm, MIPS, Stromversorgung usw.). Daher keine Abhängigkeit von markenspezifischen Merkmalen.

@Cyan4973
Könnten Sie als wirklich spätes Follow-up einige Einblicke in das neue XXH3 im Vergleich zu crc32c geben?

Hardware crc32c allein ist nicht wettbewerbsfähig. Obwohl es sicherlich schneller ist als Software crc32, kann es nicht mit ILP mithalten, das die meisten modernen Hash-Algorithmen verwenden.

Allerdings können mehrere crc32c Kanäle gleichzeitig effizienter sein. In diesem Fall ist das genaue Ergebnis implementierungsabhängig. Viele Implementierungen können über das Internet gefunden werden. Ich habe mehrere Implementierungen gefunden, die die Geschwindigkeit von XXH64 verbessern können, aber noch keine, die XXH3 besten kann. Vielleicht ist es eine Frage der Suche mehr.

CRC32 und CRC32C können sehr effizient mit Intels pclmulqdq- oder ARMv8-CLMUL-Befehlen implementiert werden.

Vor einiger Zeit habe ich einige ARM-Implementierungen mit CRC32- und CLMUL-Anweisungen zusammengestellt und ihre Geschwindigkeiten bewegen sich auf rk3399 um 4,1 GB / s. Jetzt habe ich sie mit xxh32 und xxh64 verglichen und habe 3,5 GB/s bzw. 2,5 GB/s erhalten.

Wird erwartet, dass xxh64 auf ARMv8 langsamer ist als xxh32, oder stimmt etwas nicht?

Es wird erwartet, dass xxh64 xxh32 32-Bit-Binärdateien langsamer ist als
Bei 64-Bit-Binärdateien ist dies jedoch weniger wahrscheinlich, aber man kann sich immer noch einen Chip vorstellen, der schwache / langsame 64-Bit-Multiplikationsbefehle bietet, viel langsamer als 32-Bit-Befehle. In diesem Fall ist es möglich.
Leider ist die ARMv8-Chipfamilie ziemlich groß, und jeder Chip kann sehr unterschiedliche Leistungskompromisse aufweisen. Also würde ich sagen, dass dieser Fall irgendwo passieren muss, aber ich würde es nicht zur Regel machen.

Für einen schnelleren 64-Bit-Hash auf ARM könnten Sie daran interessiert sein, das neuere XXH3_64bit() auszuprobieren, das in der neuesten Version enthalten ist.

Vielen Dank!
Binärdateien sind 64bit.
XXH3_64bit schneidet definitiv besser ab. Ohne NEON-Vektorisierung erhalte ich 3,9 GB/s und mit NEON fast 4,0 GB/s. Trotzdem hat CRC32 mit vmull_p64 einen etwas besseren Durchsatz.