基于按位與的 就散策略

總覽

編年史有很多用于哈希的實現(xiàn)，包括City和Murmur。 它也有自己的香草哈希，但是如何測試呢？

什么是香草哈希？

Vanilla Hash設(shè)計得盡可能簡單，并且針對Orthogonal Bits測試進(jìn)行了優(yōu)化（請參見下文），并與City 1.1和Murmur 3哈希策略進(jìn)行了比較。

這是用新數(shù)據(jù)填充64字節(jié)/ 256字節(jié)緩沖區(qū)并生成64位哈希值的99％延遲。 JMH用于執(zhí)行測量。 請參閱Main64bytes和Main256bytes

散列策略64字節(jié)99％瓦片256字節(jié)99％瓦片

香草	67 ns	112毫微秒
城市1.1	90納秒	182 ns
雜音3	104毫微秒	211 ns

• 完整的測試結(jié)果在這里。

您可以執(zhí)行哪些測試來檢查哈希策略是否良好？

您可以執(zhí)行許多簡單的測試。 測試無法識別出良好的哈希，但可以將哈希顯示為不良哈希。 通過一項測試可能意味著它將通過另一項測試。

在每種情況下，都使用不同的隨機(jī)起點運行多個測試。 分?jǐn)?shù)為第99％，即最差的1％。 這是因為您不需要在某些時間或平均情況下有效的哈希。 您需要一種大多數(shù)情況下都可以使用的產(chǎn)品。 （在所有情況下，您都可以發(fā)明任何特定散列都將分解的病理情況）

為了保持一致性，分?jǐn)?shù)越低越好。 測試的構(gòu)造應(yīng)使得分為0表示測試已損壞。

在每個測試中，使用8,192位或1024 KB的輸入，一次切換一位。 根據(jù)這些輸入，將生成8,192 x 64位哈希。

但是，對于隨機(jī)測試，采用了一系列隨機(jī)的64位值。 這些對于了解所測試的散列策略有多少是有用的。

哈希表掩碼

在此測試中，每個哈希為模數(shù)乘以16,384（哈希數(shù)的兩倍），并報告了沖突數(shù)。 大多數(shù)哈希策略在此測試中效果很好。

雪崩分?jǐn)?shù)

在此測試中，將每個散列與前一個散列（前一位進(jìn)行切換）進(jìn)行比較，以查看任何給定位被翻轉(zhuǎn)的可能性。 理想值為50％，得出的差值與50％的總和為最差的1％。

延遲速度

在此測試中，記錄了執(zhí)行哈希所需的時間，并報告了最差的1％延遲。

正交鉆頭

該測試的目的是確保所有散列的位與所產(chǎn)生的其他所有散列都盡可能不同。 除了64位數(shù)字外，請考慮8個皇后問題。 理想的情況是每個數(shù)字都具有與其他每個數(shù)字不同的相同位數(shù)，并且位數(shù)應(yīng)盡可能高。

在此測試中，將每個哈希與其他每個哈希進(jìn)行比較。 對不同的位數(shù)進(jìn)行計數(shù)。 如果不同位數(shù)小于18，則給出2 ^（17-n）的懲罰分?jǐn)?shù)。 位數(shù)越少，指數(shù)級的懲罰越大。 如果映射到其他8K哈希值的任何8K哈希值的差異小于5位，那么即使所有其他對都很好，這也是失敗的。

我稱其為正交位測試，因為您可以將64位數(shù)字建模為64位的位向量。 理想情況下，您希望產(chǎn)生的所有散列之間的角度盡可能大。

在所有測試中，此測試顯示具有HashMap.hash（int）的String.hashCode（）與其他哈希策略之間的最大差異。

測試String.hashCode（）

String.hashCode（）是一個非常差的哈希，尤其是對于低位 。 它是標(biāo)準(zhǔn)的，不能更改或破壞向后兼容性。 但是，這不一定是問題，因為HashMap使用agitate函數(shù)，該函數(shù)會降低一些較高的位以將較低的位隨機(jī)化。

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); }

結(jié)果

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的一部分

結(jié)論

Vanilla，City和Murmur哈希是最快的。

盡管String.hashCode（）很簡單，但每個字符的乘法運算卻很昂貴。 相比之下，所有其他字節(jié)使用long一次處理8個字節(jié)。 與STRING32相比，請參閱STRINGS32_WITHOUT_AGITATE。 HashMap使用更高版本。

即使在avalanche測試中，帶有攪動的32位String hashCode（）也表現(xiàn)不佳。 在SMHasher中，該測試的得分超過1％，被視為失敗。

哈希掩碼測試雖然簡單，但在所有情況下都表現(xiàn)良好。 例外是String.hashCode（），如上所述，它沒有非常隨機(jī)的低位。

我發(fā)現(xiàn)有趣的是，正交測試得分有何不同。 前三個哈希策略再次始終保持較低水平。 甚至String.hashCode（）的64位版本在產(chǎn)生散列方面也有很大的變化，只有不到18位的不同，實際上很多位是相同的。

免責(zé)聲明

香草哈希已針對正交鉆頭測試進(jìn)行了優(yōu)化。 因此，獲得更好的結(jié)果也就不足為奇了。 這并不意味著Vanilla Hash優(yōu)于City或Murmur。 這可能僅表示對“正交位”測試最好。

翻譯自: https://www.javacodegeeks.com/2015/08/comparing-hashing-strategies.html

基于按位與的 就散策略

總結(jié)

以上是生活随笔為你收集整理的基于按位与的 就散策略_比较散列策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。