Xxhash: ベンチマークにMeowハッシュを追加する

meow_hashは、ハードウェアアクセラレーションによるAES命令の存在に完全に依存しています。

コードがかなり短く、ソフトウェアのバックアップコードパスが表示されないため、これらの命令がないとコンパイルすらできないと思います。 その上、私が読むことができたすべてのAES命令は、直接Intel組み込み関数を使用しているため、ハードウェア機能に関係なく、アーキテクチャ間で移植性はありません。

それは必ずしも「悪い」ことではありません：結局のところ、彼らは見返りに長い入力のために素晴らしいスピードを手に入れます。

しかし、重要な点は、そのような特殊なハードウェア命令セットに依存しているため、移植性は機能リストから外れているということです。

副作用として、xxHashベンチマークに使用されるプラットフォームでも実行されません。

多分私はこれを文書化するのに少し時間を費やすべきです。

これはもはや真実ではありません。これを再検討する必要があります。

ええ、アナウンスを読んで、ニャーはいくつかの改訂で大幅に改善されました。
ARMとの互換性も発表しています。

それをより深く調べるには少し時間が必要です。

ざっと見ただけで、ソフトウェアのバックアップパスが見つかりませんでした。 多分それはそこにあり、私はそれを逃しただけです。
また、異なるAESハードウェアモジュールがまったく同じハッシュ値を生成することが保証されているかどうか、またはそれ以上のものがあるかどうかはまだわかりません（異なるプリセットがあり、マシン固有の命令を統一する必要がある追加のパラメーターなど）。 ローカルでハッシュを計算して消費することは1つのことです。その場合、正確な表現は重要ではありません。 値を書き込み/シリアル化し、他のシステムで正確に読み取り/再生成されることを期待するのも別の方法です。 相互運用性のその部分はもう少し注意が必要です。
しかし、もう一度、多分それはそこにあります、そして私はそれを調べるために少し時間が必要です。

参考までに、これは私の最新バージョンである2.0 GHz Core i7 Gen 2（Sandy Bridge）に対するものです。

Clang 7.0.1
フラグ： -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)

-march=penryn -mno-sse4.2 -mno-avxと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)

これはもはや真実ではありませんあなたはこれを再訪する必要があります

... aaand Meow 0.5では、それは再び真実です。 最新バージョンでは、x64AESコードパスしかありません:)

そうですね、MeowHashはx86_64とNehalem +に固有のものであるか、低速のafフォールバックバージョンに切り替える必要があります。

一方、XXH3は、すべてのx86_64（Core 2およびその仲間を含む）、Pentium 4+（Windows 7以降に必要）、ARMv7-A w / NEON（ほとんどのAndroidおよび元のiPhoneを除くすべてのiOSデバイスで利用可能）のコードパスをベクトル化しました。 ）、ARM64（最近のすべてのiPhoneとAndroid）、VSX POWER9（多くのサーバーとスーパーコンピューターにこれらがありますが、それはニッチな市場です）、そしてそれが十分でない場合は、スカラーバージョンでさえ32ビットでも非常に高速です彼らはまともな乗数を持っていることを考えると、ターゲット。

何年にもわたってこの種のリクエストがいくつかあったので、私はさらにいくつかのベンチマーク結果を収集し始めています。
これから始めて、これは繰り返しの要求でした。

meowHashは確かに非常に高速で、大きなデータ（〜100 KB）のXXH3とほぼ同じ速度であるため、 XXH128よりも少し高速です。
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

そうは言っても、 meowHashは実際には大規模なデータ用に設計されています。 _small_データに関しては、アルゴリズムが大きな固定費を必要とし、小さなデータでは十分に償却されないため、パフォーマンスは比較できません。

心配な展開は、「結果の表現方法と解釈方法」に矛盾があることです。
大きなデータの場合、それはかなり単純であり、ソートされたテーブルで十分であり、ランキングの即時のアイデアを提供します。
ただし、小さなデータの場合は、より複雑に見えます。
これまで、グラフを使用して、さまざまな長さとシナリオごとの速度結果を提供してきました。 _more_情報を取り上げているため、解釈が必然的に難しくなります。

結果として、読者が目立つ上部の表で最初のパフォーマンスの数値を見つけた後、追加のグラフをわざわざ下で探して、そのユースケースの重要な情報を見逃す可能性がある一方で、その選択を導くかどうかは不明です。

もう1つの問題は、グラフ自体に関するものです。 ソートされたテーブルは、比較的簡単に拡張できます。 確かに限界はありますが、一般的に言って、候補を追加すると1行だけ追加されます。
ただし、グラフでは、各候補は線で表されます。 線が重なる傾向があります。 選択できる色は非常に多いなどです。非常に迅速に、表現された候補のnbが大きい場合、それは大きな混乱にすぎません。
したがって、小さなデータのパフォーマンスにグラフが必要な場合、表現できる候補の数が大幅に制限されます。

「生の」ベンチマークデータを含む段落を追加することは称賛に値しますが、不十分な代替手段です。

したがって、私は、小さなデータのテスト結果を「要約」し、ランク付けされたテーブルで使用できる「パフォーマンス数値」を作成して、少なくとも小さなデータの一般的なパフォーマンスのヒントを与えることを検討していました。 興味のある読者は、より正確な情報（グラフ）を探す必要がありますが、少なくとも、一部のアルゴリズムが他のアルゴリズムよりも小さなデータに適しているという概念は、比較的簡単な方法で伝えることができます。

グラフは限られた数の候補しか表せないという問題がまだあり、読者が観察したいものが選択されたリストの一部ではない可能性があります（生データが利用可能な場合でも）。

グラフを表現するもっと良い方法があるのではないかと思っていました。 準備されたスクリーンショットよりも動的なもので、ユーザーはどの候補を表示するかを選択できます。

比較して追加されたmeowハッシュ：
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

テーブルにエントリを追加しても問題ありません。
しかし、私はまだ多数の候補者のグラフを描くためのより良い方法が必要です。