速度と衝突回数を測定して、いくつかの異なるアルゴリズムをテストしました。
3つの異なるキーセットを使用しました。
各コーパスについて、衝突の数とハッシュに費やされた平均時間を記録しました。
私はテストしました：
結果
各結果には、平均ハッシュ時間と衝突数が含まれます
Hash Lowercase Random UUID Numbers
============= ============= =========== ==============
Murmur 145 ns 259 ns 92 ns
6 collis 5 collis 0 collis
FNV-1a 152 ns 504 ns 86 ns
4 collis 4 collis 0 collis
FNV-1 184 ns 730 ns 92 ns
1 collis 5 collis 0 collis▪
DBJ2a 158 ns 443 ns 91 ns
5 collis 6 collis 0 collis▪▪▪
DJB2 156 ns 437 ns 93 ns
7 collis 6 collis 0 collis▪▪▪
SDBM 148 ns 484 ns 90 ns
4 collis 6 collis 0 collis**
SuperFastHash 164 ns 344 ns 118 ns
85 collis 4 collis 18742 collis
CRC32 250 ns 946 ns 130 ns
2 collis 0 collis 0 collis
LoseLose 338 ns - -
215178 collis
注：
衝突は実際に起こりますか？
はい。ハッシュの衝突が実際に起こるかどうかを確認するためにテストプログラムを書き始めました。彼らは実際に起こります：
FNV-1の衝突
FNV-1aの衝突
costarring 衝突する liquiddeclinate 衝突する macallumsaltarage 衝突する zinkealtarages 衝突する zinkes
Murmur2の衝突
cataract 衝突する peritiroquette 衝突する skivieshawl 衝突する stormbounddowlases 衝突する tramontanecricketings 衝突する twangerlongans 衝突する whigs
DJB2コリジョン
hetairas 衝突する mentionerheliotropes 衝突する neurosporadepravement 衝突する serafinsstylist 衝突する subgenerajoyful 衝突する synaphearedescribed 衝突する uritesdram 衝突する vivency
DJB2aの衝突
haggadot 衝突する loathsomenessesadorablenesses 衝突する rentabilityplaywright 衝突する snushplaywrighting 衝突する snushingtreponematoses 衝突する waterbeds
CRC32コリジョン
codding 衝突する gnuexhibiters 衝突する schlager
SuperFastHashの衝突
dahabiah 衝突する drapabilityencharm 衝突する enclavegrahams 衝突する gramary- ... 79回の衝突...
night 衝突する vigilnights 衝突する vigilsfinks 衝突する vinic
ランダムネス化
もう1つの主観的な尺度は、ハッシュがどの程度ランダムに分散されているかです。結果のHashTablesをマッピングすると、データが均等に分散されることがわかります。テーブルを線形にマッピングすると、すべてのハッシュ関数が良好な分布を示します。
または、ヒルベルトマップとして（XKCDは常に関連します）：
番号文字列（ハッシュする場合を除き"1"、"2"、...、 "216553"）（例えば、郵便番号パターンは、ハッシュアルゴリズムのほとんどに出現し始めます）、：
SDBM：
DJB2a：
FNV-1：
FNV-1aを除くすべては、まだ私にはかなりランダムに見えます：
実際、Murmur2は次のものよりもランダム性がさらに優れているようNumbersですFNV-1a。
私が見たときFNV-1a「番号」マップ、私は考えて、私は微妙な縦パターンを参照してください。つぶやきでは、パターンはまったく見られません。どう思いますか？
*表の余分は、ランダム性がどれほど悪いかを示しています。FNV-1a最高であること、そしてDJB2x最悪のこと：
Murmur2: .
FNV-1a: .
FNV-1: ▪
DJB2: ▪▪
DJB2a: ▪▪
SDBM: ▪▪▪
SuperFastHash: .
CRC: ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
Loselose: ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
▪
▪▪▪▪▪▪▪▪▪▪▪▪▪
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
私はもともとこのプログラムを書いて、衝突について心配する必要があるかどうかを判断しました。
そして、ハッシュ関数が十分にランダムであることを確認することになりました。
FNV-1aアルゴリズム
FNV1ハッシュには、32、64、128、256、512、および1024ビットのハッシュを返すバリアントがあります。
FNV-1aのアルゴリズムは次のとおりです。
hash = FNV_offset_basis
for each octetOfData to be hashed
hash = hash xor octetOfData
hash = hash * FNV_prime
return hash
定数FNV_offset_basisとFNV_prime戻りハッシュサイズに依存する場所：
Hash Size
===========
32-bit
prime: 2^24 + 2^8 + 0x93 = 16777619
offset: 2166136261
64-bit
prime: 2^40 + 2^8 + 0xb3 = 1099511628211
offset: 14695981039346656037
128-bit
prime: 2^88 + 2^8 + 0x3b = 309485009821345068724781371
offset: 144066263297769815596495629667062367629
256-bit
prime: 2^168 + 2^8 + 0x63 = 374144419156711147060143317175368453031918731002211
offset: 100029257958052580907070968620625704837092796014241193945225284501741471925557
512-bit
prime: 2^344 + 2^8 + 0x57 = 35835915874844867368919076489095108449946327955754392558399825615420669938882575126094039892345713852759
offset: 9659303129496669498009435400716310466090418745672637896108374329434462657994582932197716438449813051892206539805784495328239340083876191928701583869517785
1024-bit
prime: 2^680 + 2^8 + 0x8d = 5016456510113118655434598811035278955030765345404790744303017523831112055108147451509157692220295382716162651878526895249385292291816524375083746691371804094271873160484737966720260389217684476157468082573
offset: 1419779506494762106872207064140321832088062279544193396087847491461758272325229673230371772250864096521202355549365628174669108571814760471015076148029755969804077320157692458563003215304957150157403644460363550505412711285966361610267868082893823963790439336411086884584107735010676915
詳細については、メインのFNVページを参照してください。
私のすべての結果は、32ビット版のものです。
FNV-1はFNV-1aよりも優れていますか？
いいえ。FNV-1aの方が優れています。英語の単語コーパスを使用すると、FNV-1aとの衝突がさらに多くなりました。
Hash Word Collisions
====== ===============
FNV-1 1
FNV-1a 4
小文字と大文字を比較します。
Hash lowercase word Collisions UPPERCASE word collisions
====== ========================= =========================
FNV-1 1 9
FNV-1a 4 11
この場合、FNV-1aはFN-1よりも「400％」悪くなく、20％だけ悪いです。
より重要なことは、衝突に関しては2つのクラスのアルゴリズムがあることだと思います。
- まれな衝突：FNV-1、FNV-1a、DJB2、DJB2a、SDBM
- 一般的な衝突：SuperFastHash、Loselose
そして、ハッシュがどの程度均等に分散されているかがあります。
- 顕著な分布： Murmur2、FNV-1a、SuperFastHas
- 優れた分布： FNV-1
- 良好な分布： SDBM、DJB2、DJB2a
- 恐ろしい分布：ロセロース
更新
つぶやき？もちろん
更新
@whatshisnameは、CRC32がどのように機能するか疑問に思い、表に数字を追加しました。
CRC32はかなり良いです。衝突はほとんどありませんが、速度が遅く、1kルックアップテーブルのオーバーヘッドです。
CRC分布に関するすべての誤った情報を切り取る-悪い
今日まで、事実上のハッシュテーブルハッシュアルゴリズムとしてFNV-1aを使用していました。しかし、今私はMurmur2に切り替えています：
- もっと早く
- 入力のすべてのクラスのランダム性の改善
そして、本当にSuperFastHash見つけたアルゴリズムに何か問題があることを本当に願っています。そんなに人気があるのは残念だ。
更新：GoogleのMurmurHash3ホームページから：
（1）-SuperFastHashの衝突特性は非常に低く、他の場所で文書化されています。
だから、私だけではないようです。
更新：なぜMurmur他のものよりも高速であることに気付きました。MurmurHash2は、一度に4バイトで動作します。ほとんどのアルゴリズムはバイトごとです：
for each octet in Key
AddTheOctetToTheHash
これは、キーが長くなるとMurmurが光るチャンスを得ることを意味します。
更新
Raymond Chenによるタイムリーな投稿では、「ランダムな」 GUIDがランダム性のために使用されることを意図していないという事実を繰り返し述べています。それら、またはそれらのサブセットは、ハッシュキーとして不適切です。
バージョン4のGUIDアルゴリズムであっても、アルゴリズムは乱数ジェネレーターの品質を指定しないため、予測不能であることは保証されていません。GUIDのWikipediaの記事には、乱数ジェネレーターの状態に関する知識に基づいて、ジェネレーターが暗号的に強力ではないため、将来および以前のGUIDを予測できることを示唆する主要な研究が含まれています。
Randomessは衝突回避と同じではありません。これが、「ランダム」なGUIDのサブセットを取得して、独自の「ハッシュ」アルゴリズムを発明しようとするのが間違いになる理由です。
int HashKeyFromGuid(Guid type4uuid)
{
//A "4" is put somewhere in the GUID.
//I can't remember exactly where, but it doesn't matter for
//the illustrative purposes of this pseudocode
int guidVersion = ((type4uuid.D3 & 0x0f00) >> 8);
Assert(guidVersion == 4);
return (int)GetFirstFourBytesOfGuid(type4uuid);
}
注：繰り返しますが、「ランダムなGUID」を引用符で囲みます。これは、GUIDの「ランダムな」バリアントであるためです。より正確な説明は次のようになりますType 4 UUID。しかし、タイプ4またはタイプ1、3、5が何であるかは誰にもわかりません。したがって、それらを「ランダムな」GUIDと呼ぶ方が簡単です。
すべての英単語ミラー