基于按位与的 就散策略_比较散列策略
基于按位與的 就散策略
總覽
編年史有很多用于哈希的實現,包括City和Murmur。 它也有自己的香草哈希,但是如何測試呢?
什么是香草哈希?
Vanilla Hash設計得盡可能簡單,并且針對Orthogonal Bits測試進行了優化(請參見下文),并與City 1.1和Murmur 3哈希策略進行了比較。
這是用新數據填充64字節/ 256字節緩沖區并生成64位哈希值的99%延遲。 JMH用于執行測量。 請參閱Main64bytes和Main256bytes
| 香草 | 67 ns | 112毫微秒 |
| 城市1.1 | 90納秒 | 182 ns |
| 雜音3 | 104毫微秒 | 211 ns |
- 完整的測試結果在這里。
您可以執行哪些測試來檢查哈希策略是否良好?
您可以執行許多簡單的測試。 測試無法識別出良好的哈希,但可以將哈希顯示為不良哈希。 通過一項測試可能意味著它將通過另一項測試。
在每種情況下,都使用不同的隨機起點運行多個測試。 分數為第99%,即最差的1%。 這是因為您不需要在某些時間或平均情況下有效的哈希。 您需要一種大多數情況下都可以使用的產品。 (在所有情況下,您都可以發明任何特定散列都將分解的病理情況)
為了保持一致性,分數越低越好。 測試的構造應使得分為0表示測試已損壞。
在每個測試中,使用8,192位或1024 KB的輸入,一次切換一位。 根據這些輸入,將生成8,192 x 64位哈希。
但是,對于隨機測試,采用了一系列隨機的64位值。 這些對于了解所測試的散列策略有多少是有用的。
哈希表掩碼
在此測試中,每個哈希為模數乘以16,384(哈希數的兩倍),并報告了沖突數。 大多數哈希策略在此測試中效果很好。
雪崩分數
在此測試中,將每個散列與前一個散列(前一位進行切換)進行比較,以查看任何給定位被翻轉的可能性。 理想值為50%,得出的差值與50%的總和為最差的1%。
延遲速度
在此測試中,記錄了執行哈希所需的時間,并報告了最差的1%延遲。
正交鉆頭
該測試的目的是確保所有散列的位與所產生的其他所有散列都盡可能不同。 除了64位數字外,請考慮8個皇后問題。 理想的情況是每個數字都具有與其他每個數字不同的相同位數,并且位數應盡可能高。
在此測試中,將每個哈希與其他每個哈希進行比較。 對不同的位數進行計數。 如果不同位數小于18,則給出2 ^(17-n)的懲罰分數。 位數越少,指數級的懲罰越大。 如果映射到其他8K哈希值的任何8K哈希值的差異小于5位,那么即使所有其他對都很好,這也是失敗的。
我稱其為正交位測試,因為您可以將64位數字建模為64位的位向量。 理想情況下,您希望產生的所有散列之間的角度盡可能大。
在所有測試中,此測試顯示具有HashMap.hash(int)的String.hashCode()與其他哈希策略之間的最大差異。
測試String.hashCode()
String.hashCode()是一個非常差的哈希,尤其是對于低位 。 它是標準的,不能更改或破壞向后兼容性。 但是,這不一定是問題,因為HashMap使用agitate函數,該函數會降低一些較高的位以將較低的位隨機化。
int hash(int h) {// This function ensures that hashCodes that differ only by// constant multiples at each bit position have a bounded// number of collisions (approximately 8 at default load factor).h ^= (h >>> 20) ^ (h >>> 12);return h ^ (h >>> 7) ^ (h >>> 4); }結果
CheckMain類對每種哈希策略運行一套測試。
VANILLA Orthogonal bits: 99%tile score: 6066 Speed: The 99%tile for latency was 0.223 us Avalanche: The 99%tile of the drift from 50% was 0.55% Mask of Hash: 99%tile collisions: 1815CITY_1_1 Orthogonal bits: 99%tile score: 7395 Speed: The 99%tile for latency was 0.267 us Avalanche: The 99%tile of the drift from 50% was 0.55% Mask of Hash: 99%tile collisions: 1817MURMUR_3 Orthogonal bits: 99%tile score: 7524 Speed: The 99%tile for latency was 0.378 us Avalanche: The 99%tile of the drift from 50% was 0.54% Mask of Hash: 99%tile collisions: 1815STRING32 Orthogonal bits: 99%tile score: 295906433 Speed: The 99%tile for latency was 1.580 us Avalanche: The 99%tile of the drift from 50% was 1.02% Mask of Hash: 99%tile collisions: 1814STRING64 Orthogonal bits: 99%tile score: 1939167 Speed: The 99%tile for latency was 1.520 us Avalanche: The 99%tile of the drift from 50% was 0.61% Mask of Hash: 99%tile collisions: 1816STRING32_WITHOUT_AGITATE Orthogonal bits: 99%tile score: 879390386 Speed: The 99%tile for latency was 1.573 us Avalanche: The 99%tile of the drift from 50% was 3.53% Mask of Hash: 99%tile collisions: 6593RANDOM Orthogonal bits: 99%tile score: 7444 Speed: The 99%tile for latency was 0.058 us Avalanche: The 99%tile of the drift from 50% was 0.53% Mask of Hash: 99%tile collisions: 1817SECURE_RANDOM Orthogonal bits: 99%tile score: 7449 Speed: The 99%tile for latency was 0.861 us Avalanche: The 99%tile of the drift from 50% was 0.54% Mask of Hash: 99%tile collisions: 1816SEEDED_VANILLA Orthogonal bits: 99%tile score: 6000 Speed: The 99%tile for latency was 0.219 us Avalanche: The 99%tile of the drift from 50% was 0.55% Mask of Hash: 99%tile collisions: 1814SEEDED_CITY_1_1 Orthogonal bits: 99%tile score: 7313 Speed: The 99%tile for latency was 0.270 us Avalanche: The 99%tile of the drift from 50% was 0.54% Mask of Hash: 99%tile collisions: 1813SEEDED_MURMUR_3 Orthogonal bits: 99%tile score: 7404 Speed: The 99%tile for latency was 0.359 us Avalanche: The 99%tile of the drift from 50% was 0.53% Mask of Hash: 99%tile collisions: 1810注意: Vanilla Hash種子是Chronicle Enterprise的一部分
結論
Vanilla,City和Murmur哈希是最快的。
盡管String.hashCode()很簡單,但每個字符的乘法運算卻很昂貴。 相比之下,所有其他字節使用long一次處理8個字節。 與STRING32相比,請參閱STRINGS32_WITHOUT_AGITATE。 HashMap使用更高版本。
即使在avalanche測試中,帶有攪動的32位String hashCode()也表現不佳。 在SMHasher中,該測試的得分超過1%,被視為失敗。
哈希掩碼測試雖然簡單,但在所有情況下都表現良好。 例外是String.hashCode(),如上所述,它沒有非常隨機的低位。
我發現有趣的是,正交測試得分有何不同。 前三個哈希策略再次始終保持較低水平。 甚至String.hashCode()的64位版本在產生散列方面也有很大的變化,只有不到18位的不同,實際上很多位是相同的。
免責聲明
香草哈希已針對正交鉆頭測試進行了優化。 因此,獲得更好的結果也就不足為奇了。 這并不意味著Vanilla Hash優于City或Murmur。 這可能僅表示對“正交位”測試最好。
翻譯自: https://www.javacodegeeks.com/2015/08/comparing-hashing-strategies.html
基于按位與的 就散策略
總結
以上是生活随笔為你收集整理的基于按位与的 就散策略_比较散列策略的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 电话网关设置(电话网关设置在哪里)
- 下一篇: 请使用复选框选择_使用可选是可选的