Xxhash: Agregue Meow hash en los puntos de referencia

meow_hash depende completamente de la presencia de instrucciones AES aceleradas por hardware.

Sospecho que ni siquiera se compilará en ausencia de estas instrucciones, ya que el código es bastante corto y no veo ninguna ruta de código de respaldo de software. Además, todas las instrucciones de AES que pude leer utilizan intrínseca Intel directa, por lo que no es portátil en toda la arquitectura, independientemente de las capacidades del hardware.

No es necesariamente algo "malo": después de todo, obtienen una gran velocidad a cambio de una entrada prolongada.

Pero el punto principal es: con la dependencia de un conjunto de instrucciones de hardware especializado, la portabilidad está fuera de la lista de funciones.

Como efecto secundario, ni siquiera se ejecutaría en la plataforma utilizada para los puntos de referencia xxHash.

Quizás debería dedicar un tiempo a documentar esto.

Esto ya no es cierto, debería volver a visitarlo.

Sí, leyendo los anuncios, miau ha mejorado mucho en algunas revisiones.
Incluso anuncia compatibilidad con ARM.

Necesitaré algo de tiempo para analizarlo más a fondo.

Solo hice una mirada superficial y no pude encontrar una ruta de respaldo de software. Tal vez esté ahí y simplemente me lo perdí.
Además, todavía no sé si los diferentes módulos de hardware AES están garantizados para producir exactamente el mismo valor hash, o si hay más (como parámetros adicionales que pueden estar preestablecidos de manera diferente y requieren que las instrucciones específicas de la máquina sean uniformes). Una cosa es calcular y consumir hash localmente, en cuyo caso la representación exacta no importa. Es otro escribir / serializar el valor y esperar que se lea / reproduzca exactamente en cualquier otro sistema. Esa parte de la interoperabilidad es un poco más complicada.
Pero una vez más, tal vez esté ahí, y solo necesito algo de tiempo para investigarlo.

Como referencia, esto es contra mi última versión, 2.0 GHz Core i7 Gen 2 (Sandy Bridge)

Clang 7.0.1
Banderas: -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)

Con -march=penryn -mno-sse4.2 -mno-avx y la implementación de 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)

Esto ya no es cierto, debería volver a visitar este

... aay en Miau 0.5 es verdad de nuevo; en la última versión, nuevamente solo tienen la ruta del código AES x64 :)

Así que sí, Meow Hash es un poco específico para x86_64 y Nehalem +, o tiene que cambiar a una versión de reserva lenta.

Mientras tanto, XXH3 tiene rutas de código vectorizadas para todos los x86_64 (incluidos Core 2 y amigos), Pentium 4+ (que se requiere para Windows 7+), ARMv7-A w / NEON (disponible en la mayoría de los dispositivos Android y iOS excepto el iPhone original ), ARM64 (todos los iPhones y Androids recientes), VSX POWER9 (muchos servidores y supercomputadoras los tienen, pero es un nicho de mercado), y si eso no fuera suficiente, incluso la versión escalar sigue siendo muy rápida incluso en 32 bits objetivos, dado que tienen un multiplicador decente.

Estoy empezando a recopilar algunos resultados de referencia más, ya que hubo varias solicitudes de este tipo a lo largo de los años.
Empezando por éste, que ha sido una petición recurrente.

meowHash es realmente muy rápido, con aproximadamente la misma velocidad que XXH3 para datos grandes (~ 100 KB), por lo tanto, un poco más rápido que XXH128 .
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

Dicho esto, meowHash está realmente diseñado para datos grandes. Cuando se trata de datos _pequeños_, el rendimiento no es comparable, ya que el algoritmo requiere un gran costo fijo, que se amortiza mal en datos pequeños.

Un acontecimiento preocupante es que existe una discrepancia en "cómo representar e interpretar los resultados".
Para datos grandes, es bastante simple, una tabla ordenada puede ser suficiente, dando una idea instantánea de la clasificación.
Sin embargo, para datos pequeños, parece más complejo.
Hasta ahora, he usado gráficos, proporcionando un resultado de velocidad para diferentes longitudes y escenarios. En virtud de incluir _más_ información, es necesariamente más difícil de interpretar.

Como consecuencia, no está claro si un lector, después de encontrar la primera cifra de rendimiento en la tabla superior prominente, se molestará en buscar gráficos adicionales a continuación, lo que guiará su elección y perderá potencialmente una información importante para su caso de uso.

Otro problema tiene que ver con los propios gráficos. Una tabla ordenada se puede ampliar con relativa facilidad. Hay límites, claro, pero en general, agregar un contendiente solo agrega una línea.
Sin embargo, en un gráfico, cada contendiente está representado por una línea. Las líneas tienden a superponerse. Hay un número limitado de colores para elegir, etc. Muy rápidamente, si el número de contendientes representados es grande, es un gran lío.
Por lo tanto, si el rendimiento de datos pequeños necesita un gráfico, limita severamente el número de contendientes que se pueden representar.

Agregar un párrafo que contenga datos de referencia "sin procesar", aunque es encomiable, es un mal sustituto.

Por lo tanto, estaba considerando "resumir" el resultado de la prueba de datos pequeños y crear un "número de rendimiento" que se pueda usar en una tabla clasificada, para dar al menos una pista del rendimiento general en datos pequeños. Los lectores interesados ​​todavía tendrían que buscar información más precisa (gráficos), pero al menos, la noción de que algunos algoritmos son más adecuados para datos pequeños que otros se puede transmitir de una manera relativamente simple.

Todavía existe el problema de que los gráficos solo pueden representar un número limitado de contendientes, y tal vez el que un lector quiere observar no forma parte de la lista seleccionada (incluso cuando los datos sin procesar están disponibles).

Me preguntaba si habría una mejor manera de representar gráficos. Algo más dinámico que una captura de pantalla preparada, que permite al usuario seleccionar qué contendientes deben estar visibles.

miau hash agregado en comparación:
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

Agregar una entrada a la tabla está bien.
Pero todavía necesito una mejor forma de dibujar gráficos para una gran cantidad de candidatos.