Xxhash: ARM de 32 bits muy lento xxhash

Un problema clásico con gcc en ARM de 32 bits es que
no explota (de forma predeterminada) la capacidad de la CPU para admitir el acceso a la memoria no alineada
(que supongo que el A9 puede)
resultando en accesos de memoria muy lentos.

Hay algunas cosas que se pueden intentar aquí.

En el lado de la biblioteca, existen varios métodos de acceso que se proporcionan:
https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h#L1117

El más agresivo es XXH_FORCE_MEMORY_ACCESS=2 .
Puede conducir a una generación binaria incorrecta dependiendo de otras configuraciones y capacidades del compilador.
Pero si funciona, al menos dará una idea de cuál debería ser la velocidad.

Un poco más seguro, XXH_FORCE_MEMORY_ACCESS=1 generará el código correcto.
Pero el compilador debe saber que la CPU puede acceder a direcciones de memoria no alineadas.

Esto puede requerir la especificación de algún indicador de compilación adicional.
Por ejemplo, -march=armv7a le dice a gcc que el chip arm es capaz de acceder a direcciones de memoria no alineadas,
resultando en una generación de código mucho mejor en combinación con XXH_FORCE_MEMORY_ACCESS=1 .
(Desafortunadamente, según godbolt, esta bandera asociada con el valor predeterminado XXH_FORCE_MEMORY_ACCESS=0 todavía ofrece un mal rendimiento en la versión anterior de gcc . Las versiones más nuevas gcc-6 solucionan este problema).

No estoy seguro de si es una opción, pero clang también tiende a generar un mejor código binario para el brazo.

Finalmente, del lado del usuario
suponiendo que XXH_FORCE_ALIGN_CHECK=1 (https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h#L1179),
proporcionando entrada alineada (en límites de 4 bytes por XXH32 )
debe utilizar la ruta del código de acceso a la memoria alineada directamente.
Éste no debería depender de que el compilador detecte capacidades de acceso a la memoria no alineadas,
ya que el acceso a la memoria se detecta alineado al principio.

Es probable que XXH64 tenga un rendimiento deficiente en arm 32 bits.
Pero XXH32 debería estar bien.
El XXH3 está en el saldo, la línea de base debería estar bien,
y con el soporte de neon , se espera que supere a XXH32 en velocidad.

_edit_: valor de acceso a memoria fijo, subrayado por @ easyaspi314

Si no me equivoco, las banderas de propósito general correctas para esa CPU serían las siguientes:

-O2   -fomit-frame-pointer -march=armv7-a      -mfpu=neon     -mthumb        -munaligned-access
^duh  ^saves a register    ^sets arch version  ^enables neon  ^use thumb-2   ^force enable unaligned access

Sin embargo, como dijo Yann, también recomendaría Clang, ya que tiende a generar un mejor código, especialmente con NEON.

Además, ¿probaste una versión más reciente de GCC? Los backends ARM y AArch64 de GCC son bastante mediocres, y fue bastante malo hasta hace poco.

@ Cyan4973 por cierto, XXH_FORCE_MEMORY_ACCESS=3 es seguro, 2 es el maligno.

Parece que la cadena de herramientas no activó correctamente las optimizaciones del compilador. Al configurarlos explícitamente para la compilación, los xxhashes se calculan (tan rápido como) deberían. Gracias @ Cyan4973 y @ easyaspi314.