Xxhash: crc32で速度比較を更新します

問題は、
ベンチマークはCore2 Duo @ 3GHzで実行されました。
このCPUはハードウェアcrc32cをサポートしていません。

また、crc32とcrc32cは似ていますが、アルゴリズムが異なります。同じ結果は得られません。
crc32は広く使用されていますが、crc32cはそれほど使用されていません。 このような名前の混乱は、重要な相互運用性の問題を引き起こす可能性があります。

ここでベンチに入れられたcrc32バージョンは、smasherテストスイート内で提供されているものです。
ベクトル化されたものを含む、より高速なバージョンが存在します。
それらを統合するには、テストスイートを変更する必要があります。

アプリケーションのIntel依存関係を許容でき、すべてのクライアントCPUが十分に新しいことを保証できる場合（2016年には妥当です）、ハードウェアcrc32cを使用できます。これは非常に高速です。

xxHashは、この機能のないCPUを使用し、Intelの領域（arm、mips、powerなど）をはるかに超えた最大の移植性を目的として、別のコンテキストで作成されました。 したがって、ブランド固有の機能に依存することはありません。

@ Cyan4973
本当に遅いフォローアップとして、crc32cと比較した新しいXXH3に関するいくつかの洞察を提供できますか？

ハードウェアcrc32c自体は競争力がありません。 ソフトウェアcrc32よりも確かに高速ですが、最新のハッシュアルゴリズムで使用されているILPに追いつくことはできません。

ただし、複数のcrc32cチャネルを並行して実行する方が効率的です。 その場合、正確な結果は実装に依存します。 多くの実装はインターネット上で見つけることができます。 XXH64速度に最適な実装をいくつか見つけましたが、 XXH3最適な実装はまだありません。 多分それはもっと検索することの問題です。

CRC32およびCRC32Cは、IntelのpclmulqdqまたはARMv8CLMUL命令を使用して非常に効率的に実装できます。

少し前に、CRC32およびCLMUL命令を使用していくつかのARM実装をまとめましたが、それらの速度はrk3399で約4.1GB / sで変動しています。 ここで、それらをxxh32およびxxh64と比較し、それぞれ3.5GB / sおよび2.5GB / sを取得しました。

ARMv8ではxxh64がxxh32よりも遅いと予想されますか、それとも何か問題がありますか？

xxh64は、32ビットバイナリではxxh32よりも遅いと予想されます。
64ビットバイナリでは、これは起こりそうにありませんが、32ビット命令よりもはるかに遅い64ビット乗算命令が弱い/遅いことを特徴とするチップを想像することができます。その場合、それは可能です。
残念ながら、ARMv8ファミリのチップは非常に大きく、各チップは非常に異なるパフォーマンスのトレードオフを特徴とする可能性があります。 ですから、この事件はどこかで起こらなければならないと思いますが、私はそれをルールにしません。

ARMでより高速な64ビットハッシュを使用するには、最新リリースで紹介されている新しいXXH3_64bit()を試してみることをお勧めします。

ありがとう！
バイナリは64ビットです。
XXH3_64bit間違いなくパフォーマンスが向上します。 NEONベクトル化を使用しない場合、3.9GB / sを取得し、NEONを使用すると4.0 GB / sに近くなります。 それでも、 vmull_p64を使用するCRC32のスループットはわずかに優れています。