Xxhash: Atualizar comparações de velocidade com crc32

O problema é,
benchmark foi executado em um Core 2 Duo @ 3GHz.
Esta CPU não suporta hardware crc32c.

Além disso, crc32 e crc32c são algoritmos semelhantes, mas diferentes: você não obterá os mesmos resultados.
O crc32 é amplamente utilizado, o crc32c muito menos. Essa confusão de nomenclatura pode induzir problemas de interoperabilidade não triviais.

A versão crc32 testada aqui é aquela fornecida no pacote de testes smasher.
Existem versões mais rápidas, incluindo as vetorizadas.
É necessário modificar o conjunto de testes para integrá-los.

Se você pode tolerar a dependência da Intel para seu aplicativo, e pode garantir que todos os seus cpus de cliente são recentes o suficiente (o que é razoável em 2016), você pode usar o hardware crc32c, é realmente muito rápido.

xxHash foi criado em um contexto diferente, usando uma cpu sem esse recurso e com o objetivo pretendido de portabilidade máxima, muito além do domínio da Intel (braço, mips, potência, etc.). Portanto, não há dependência de recursos específicos da marca.

@ Cyan4973
Como um acompanhamento realmente tardio, você poderia fornecer alguns insights sobre o novo XXH3 em comparação com o crc32c?

O hardware crc32c por si só não é competitivo. Embora seja certamente mais rápido do que o software crc32, ele não consegue acompanhar o ILP, que a maioria dos algoritmos de hash modernos usa.

No entanto, vários canais crc32c em paralelo podem ser mais eficientes. Nesse caso, o resultado exato depende da implementação. Muitas implementações podem ser encontradas na Internet. Eu encontrei várias implementações que podem melhor a velocidade de XXH64 , mas nenhuma ainda pode melhor que XXH3 . Talvez seja uma questão de pesquisar mais.

CRC32 e CRC32C podem ser implementados de forma muito eficiente usando as instruções pclmulqdq ou ARMv8 CLMUL da Intel.

Algum tempo atrás, eu reuni algumas implementações de ARM usando instruções CRC32 e CLMUL e suas velocidades estão flutuando em torno de 4,1 GB / s em rk3399. Agora eu os comparei com xxh32 e xxh64 e obtive 3,5 GB / se 2,5 GB / s, respectivamente.

É esperado que xxh64 seja mais lento que xxh32 no ARMv8 ou há algo errado?

Espera-se que xxh64 seja mais lento do que xxh32 em binários de 32 bits.
Em binários de 64 bits, porém, isso é menos provável, mas ainda se pode imaginar um chip que apresenta instruções de multiplicação de 64 bits fracas / lentas, muito mais lentas do que as de 32 bits, caso em que é possível.
Infelizmente, a família de chips ARMv8 é muito grande e cada chip pode apresentar uma compensação de desempenho muito diferente. Então, eu diria que esse caso tem que acontecer em algum lugar, mas não faria disso a regra.

Para obter um hash de 64 bits mais rápido no ARM, você pode estar interessado em experimentar o XXH3_64bit() mais recente, apresentado na versão mais recente.

Obrigado!
Os binários são de 64 bits.
XXH3_64bit definitivamente tem um desempenho melhor. Sem usar a vetorização NEON estou obtendo 3,9 GB / se com NEON perto de 4,0 GB / s. Ainda assim, o CRC32 usando vmull_p64 tem um rendimento um pouco melhor.