Xxhash: Adicionar hash Meow nos benchmarks

meow_hash depende inteiramente da presença de instruções AES aceleradas por hardware.

Suspeito que nem mesmo será compilado na ausência dessas instruções, pois o código é muito curto e não vejo nenhum caminho de código de backup de software. Além disso, todas as instruções AES que consegui ler usam intrínseco direto da Intel, portanto, não é portátil em toda a arquitetura, independentemente dos recursos de hardware.

Não é necessariamente uma coisa "ruim": afinal, eles obtêm grande velocidade em troca de longas entradas.

Mas o ponto principal é: com a confiança nesse conjunto de instruções de hardware especializado, a portabilidade está fora da lista de recursos.

Como efeito colateral, ele nem mesmo rodaria na plataforma usada para benchmarks xxHash.

Talvez eu deva gastar algum tempo documentando isso.

Isso não é mais verdade, você deve revisitar isso.

Sim, lendo os anúncios, o miau melhorou muito em algumas revisões.
Ele ainda anuncia compatibilidade com ARM.

Vou precisar de algum tempo para examiná-lo mais profundamente.

Eu apenas dei uma olhada superficial e não consegui encontrar um caminho de backup de software. Talvez esteja lá e eu apenas o perdi.
Além disso, não sei ainda se diferentes módulos de hardware AES têm garantia de produzir exatamente o mesmo valor de hash, ou se há mais do que isso (como parâmetros adicionais que podem ser predefinidos de forma diferente e exigem instruções específicas da máquina para serem uniformes). Uma coisa é calcular e consumir hash localmente; nesse caso, a representação exata não importa. Outra é escrever / serializar o valor e esperar que ele seja lido / reproduzido exatamente em qualquer outro sistema. Essa parte da interoperabilidade é um pouco mais complicada.
Mas, mais uma vez, talvez esteja lá, e eu só preciso de algum tempo para averiguar.

Para referência, isso é contra minha versão mais recente, 2.0 GHz Core i7 Gen 2 (Sandy Bridge)

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

Com -march=penryn -mno-sse4.2 -mno-avx e a implementação 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)

Isso não é mais verdade, você deve revisitar este

... aaand em Miau 0,5 é verdade novamente; na versão mais recente, eles têm apenas o caminho do código AES x64 :)

Então, sim, Meow Hash é meio específico para x86_64 e Nehalem +, ou tem que mudar para uma versão lenta de fallback.

Enquanto isso, XXH3 vetorizou caminhos de código para todos os x86_64 (incluindo Core 2 e amigos), Pentium 4+ (que é necessário para Windows 7 ou 7), ARMv7-A com NEON (disponível na maioria dos Androids e todos os dispositivos iOS, exceto o iPhone original ), ARM64 (todos os iPhones e Androids recentes), VSX POWER9 (muitos servidores e supercomputadores têm isso, mas é um nicho de mercado), e se isso não bastasse, mesmo a versão escalar ainda é muito rápida mesmo em 32 bits alvos, uma vez que têm um multiplicador decente.

Estou começando a reunir mais alguns resultados de benchmark, pois houve vários pedidos desse tipo ao longo dos anos.
A começar por este, que tem sido um pedido recorrente.

meowHash é realmente muito rápido, marcando aproximadamente a mesma velocidade de XXH3 para dados grandes (~ 100 KB), portanto, um pouco mais rápido do que XXH128 .
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

Dito isso, meowHash é realmente projetado para grandes volumes de dados. Quando se trata de _pequenos_ dados, o desempenho não é comparável, pois o algoritmo requer um grande custo fixo, que é mal amortizado em pequenos dados.

Um desenvolvimento preocupante é que há uma discrepância em "como representar e interpretar resultados".
Para grandes dados, é bastante simples, uma tabela ordenada pode ser suficiente, dando uma ideia instantânea da classificação.
Para dados pequenos, porém, parece mais complexo.
Até agora, usei gráficos, fornecendo um resultado de velocidade por diferentes comprimentos e cenários. Por apresentar _mais_ informações, é necessariamente mais difícil de interpretar.

Como consequência, não está claro se um leitor, depois de encontrar a primeira figura de desempenho na tabela superior proeminente, se preocupará em procurar gráficos adicionais abaixo, orientando assim sua escolha, embora potencialmente perdendo uma informação importante para seu caso de uso.

Outra questão é sobre os próprios gráficos. Uma tabela classificada pode ser estendida com relativa facilidade. Existem limites, com certeza, mas de modo geral, adicionar um contendor adiciona apenas uma linha.
No entanto, em um gráfico, cada concorrente é representado por uma linha. As linhas tendem a se sobrepor. Existem tantas cores para escolher, etc. Muito rapidamente, se o número de contendores representados for grande, é uma grande bagunça.
Portanto, se o desempenho de dados pequenos precisa de um gráfico, isso limita severamente o número de contendores que podem ser representados.

Adicionar um parágrafo contendo dados de benchmark "brutos", embora louvável, é um substituto insatisfatório.

Portanto, eu estava pensando em "resumir" o resultado do teste de pequenos dados e criar um "número de desempenho" que pode ser usado em uma tabela classificada, para dar pelo menos uma dica de desempenho geral em pequenos dados. Os leitores interessados ​​ainda teriam que procurar informações mais precisas (gráficos), mas pelo menos a noção de que alguns algoritmos são mais adequados para pequenos dados do que outros pode ser transmitida de uma maneira relativamente simples.

Ainda existe o problema de que os gráficos podem representar apenas um número limitado de contendores, e talvez aquele que o leitor deseja observar não faça parte da lista selecionada (mesmo quando dados brutos estão disponíveis).

Eu queria saber se haveria uma maneira melhor de representar gráficos. Algo mais dinâmico do que uma captura de tela preparada, permitindo ao usuário selecionar quais contendores devem ser visíveis.

hash de miau adicionado em comparação:
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

Adicionar uma entrada à tabela é bom.
Mas ainda preciso de uma maneira melhor de desenhar gráficos para um grande número de candidatos.