Xxhash: Сравнение скорости обновления с crc32

Проблема в том,
Тест проводился на Core 2 Duo с частотой 3 ГГц.
Этот процессор не поддерживает аппаратное обеспечение crc32c.

Кроме того, crc32 и crc32c похожи, но разные алгоритмы: вы не получите одинаковых результатов.
crc32 широко используется, crc32c - гораздо реже. Такая путаница с именами может вызвать нетривиальные проблемы совместимости.

Версия crc32, представленная здесь, входит в комплект тестов smasher.
Существуют более быстрые версии, в том числе векторизованные.
Требуется изменить набор тестов для их интеграции.

Если вы можете терпеть зависимость от Intel для своего приложения и можете гарантировать, что все ваши клиентские процессоры достаточно свежие (что разумно в 2016 году), вы можете затем использовать аппаратное обеспечение crc32c, это действительно очень быстро.

xxHash был создан в другом контексте, с использованием процессора без этой возможности и с предполагаемой целью максимальной переносимости, выходящей далеко за рамки Intel (arm, mips, power и т. д.). Следовательно, нельзя полагаться на особенности бренда.

@ Cyan4973
Не могли бы вы дать некоторое представление о новом XXH3 в сравнении с crc32c?

Оборудование crc32c само по себе неконкурентоспособно. Хотя он, безусловно, быстрее программного обеспечения crc32, он не успевает за ILP, который используют большинство современных алгоритмов хеширования.

Однако параллельное использование нескольких каналов crc32c может быть более эффективным. В этом случае точный результат зависит от реализации. Многие реализации можно найти в Интернете. Я нашел несколько реализаций, которые могут XXH64 скорость XXH3 . Может быть, дело в поиске большего.

CRC32 и CRC32C могут быть очень эффективно реализованы с помощью инструкций Intel pclmulqdq или ARMv8 CLMUL.

Некоторое время назад я собрал пару реализаций ARM с использованием инструкций CRC32 и CLMUL, и их скорости колеблются около 4,1 ГБ / с на rk3399. Теперь я сравнил их с xxh32 и xxh64 и получил 3,5 ГБ / с и 2,5 ГБ / с соответственно.

Ожидается ли, что xxh64 медленнее, чем xxh32 на ARMv8, или что-то не так?

Ожидается, что xxh64 медленнее, чем xxh32 на 32-битных двоичных файлах.
Однако в 64-битных двоичных файлах это менее вероятно, но все же можно представить чип, который имеет слабые / медленные 64-битные инструкции умножения, намного медленнее, чем 32-битные, и в этом случае это возможно.
К сожалению, семейство чипов ARMv8 довольно велико, и у каждого чипа может быть очень разный компромисс в производительности. Я бы сказал, что этот случай должен где-то случиться, но я бы не стал делать это правилом.

Для более быстрого 64-битного хеширования на ARM вам может быть интересно попробовать новый XXH3_64bit() , представленный в последней версии.

Спасибо!
Бинарные файлы 64-битные.
XXH3_64bit определенно работает лучше. Без использования векторизации NEON я получаю 3,9 ГБ / с, а с NEON - около 4,0 ГБ / с. Тем не менее, CRC32 с использованием vmull_p64 имеет немного лучшую пропускную способность.