Xxhash: Actualice las comparaciones de velocidad con crc32

El problema es,
El punto de referencia se ejecutó en un Core 2 Duo a 3GHz.
Esta CPU no es compatible con el hardware crc32c.

Además, crc32 y crc32c son algoritmos similares pero diferentes: no obtendrá los mismos resultados.
crc32 es ampliamente utilizado, crc32c mucho menos. Tal confusión de nombres puede inducir problemas de interoperabilidad no triviales.

La versión de crc32 almacenada aquí es la que se proporciona dentro de la suite de pruebas de Smasher.
Existen versiones más rápidas, incluidas las vectorizadas.
Requiere modificar el conjunto de pruebas para integrarlos.

Si puede tolerar la dependencia de Intel para su aplicación y puede garantizar que todos los cpus de su cliente sean lo suficientemente recientes (lo cual es razonable en 2016), puede usar el hardware crc32c, de hecho, es muy rápido.

xxHash se creó en un contexto diferente, utilizando una CPU sin esta capacidad y con el objetivo de máxima portabilidad, mucho más allá del ámbito de Intel (arm, mips, power, etc.). Por tanto, no hay que depender de las características específicas de la marca.

@ Cyan4973
Como seguimiento realmente tardío, ¿podría proporcionar algunas ideas sobre el nuevo XXH3 en comparación con crc32c?

El hardware crc32c por sí solo no es competitivo. Si bien es ciertamente más rápido que el software crc32, no puede seguir el ritmo de ILP, que utilizan la mayoría de los algoritmos hash modernos.

Sin embargo, varios canales crc32c en paralelo pueden ser más eficientes. En cuyo caso, el resultado exacto depende de la implementación. Se pueden encontrar muchas implementaciones en Internet. Encontré varias implementaciones que pueden mejorar la velocidad de XXH64 , pero ninguna que pueda mejorar XXH3 . Quizás sea cuestión de buscar más.

CRC32 y CRC32C se pueden implementar de manera muy eficiente utilizando las instrucciones pclmulqdq o ARMv8 CLMUL de Intel.

Hace algún tiempo, armé un par de implementaciones ARM usando instrucciones CRC32 y CLMUL y sus velocidades están flotando alrededor de 4.1GB / s en rk3399. Ahora los comparé con xxh32 y xxh64 y obtuve 3.5GB / sy 2.5GB / s respectivamente.

¿Se espera que xxh64 sea más lento que xxh32 en ARMv8 o hay algún problema?

Se espera que xxh64 sea ​​más lento que xxh32 en binarios de 32 bits.
Sin embargo, en binarios de 64 bits, esto es menos probable, pero aún se puede imaginar un chip que presenta instrucciones de multiplicación débiles / lentas de 64 bits, mucho más lentas que las de 32 bits, en cuyo caso, es posible.
Desafortunadamente, la familia de chips ARMv8 es bastante grande y cada chip puede presentar una compensación de rendimiento muy diferente. Entonces yo diría que este caso tiene que suceder en alguna parte, pero no lo convertiría en la regla.

Para obtener un hash de 64 bits más rápido en ARM, es posible que le interese probar el XXH3_64bit() , incluido en la última versión.

¡Gracias!
Los binarios son de 64 bits.
XXH3_64bit definitivamente funciona mejor. Sin usar la vectorización NEON obtengo 3.9GB / sy con NEON cerca de 4.0 GB / s. Sin embargo, todavía CRC32 usando vmull_p64 tiene un rendimiento ligeramente mejor.