Чому хеш-код () Java у String використовує 31 як множник?

Відповідно до документації Java, хеш-код для Stringоб'єкта обчислюється як:

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

з використанням intарифметичних операцій, де s[i]це я й символ рядка, nдовжина рядка, і ^вказує , зведення в ступінь.

Чому 31 використовується як множник?

Я розумію, що множник повинен бути порівняно великим простим числом. То чому б не 29, 37, а то й 97?

Відповідно до Ефективної Java Джошуа Блоха (книги, яку недостатньо рекомендувати, і яку я придбав завдяки постійним згадкам про stackoverflow):

Значення 31 було обрано тому, що це непарний простий показник. Якби воно було парним, і множення переповнилося, інформація втрачалася б, оскільки множення на 2 еквівалентно зміщенню. Перевага використання прайме менш зрозуміла, але традиційна. Приємне властивість 31 є те , що множення може бути замінено на зрушення і відніманням для кращої продуктивності: 31 * i == (i << 5) - i. Сучасні віртуальні машини роблять подібну оптимізацію автоматично.

.

Як зазначають Гудрич і Тамасія , якщо ви візьмете понад 50 000 англійських слів (сформованих як об'єднання списків слів, передбачених у двох варіантах Unix), використання констант 31, 33, 37, 39 і 41 призведе до менш ніж 7 зіткнень у кожному випадку. Знаючи це, не дивно, що багато реалізацій Java вибирають одну з цих констант.

Випадково я опинився в середині читання розділу "поліномальні хеш-коди", коли побачив це запитання.

EDIT: тут посилання на ~ 10mb PDF-книжку, на яку я згадуюсь вище. Дивіться розділ 10.2 Таблиці хеш-структур (стор. 413) структур даних та алгоритмів Java

На (переважно) старих процесорах множення на 31 може бути порівняно дешевим. Наприклад, для ARM це лише одна інструкція:

RSB       r1, r0, r0, ASL #5    ; r1 := - r0 + (r0<<5)

Більшість інших процесорів потребують окремої інструкції зсуву та віднімання. Однак якщо ваш множник повільний, це все-таки виграш. Сучасні процесори, як правило, мають швидкі мультиплікатори, тому це не має великої різниці, доки 32 йдуть на правильну сторону.

Це не чудовий алгоритм хешування, але він досить хороший і кращий, ніж код 1.0 (і набагато краще, ніж 1.0 специфікація!).

Помноживши, біти зміщуються вліво. Тут використовується більше доступного простору хеш-кодів, що зменшує зіткнення.

Не використовуючи потужність двох, заповнюються також і найменші біти нижнього порядку, які змішуються з наступним фрагментом даних, що надходить у хеш.

Вираз n * 31рівносильний (n << 5) - n.

Ви можете прочитати оригінальні міркування Блоха в розділі "Коментарі" на http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4045622 . Він досліджував виконання різних хеш-функцій стосовно отриманого "середнього розміру ланцюга" в хеш-таблиці. P(31)була однією з найпоширеніших функцій того часу, яку він виявив у книзі K&R (але навіть Керніган та Річі не могли згадати, звідки вона походить). Врешті-решт, він в основному повинен був вибрати один, і тому він взяв, P(31)оскільки, здавалося, він працює досить добре. Незважаючи на те, що P(33)насправді було не гірше, і множення на 33 однаково швидко обчислити (лише зміна на 5 і додавання), він вибрав 31, оскільки 33 не є простим:

З решти чотирьох я, мабуть, обрав би P (31), оскільки це найдешевший підрахунок на машині RISC (адже 31 - різниця двох потужностей двох). P (33) аналогічно дешевий для обчислення, але його продуктивність незначно гірша, а 33 - композитний, що робить мене трохи нервовим.

Отже, міркування були не настільки раціональними, як, здається, багато відповідей тут. Але ми всі хороші в тому, щоб виходити з раціональних причин після рішення кишок (і навіть Блох може бути схильним до цього).

Насправді 37 працювали б досить добре! z: = 37 * x можна обчислити як y := x + 8 * x; z := x + 4 * y. Обидва кроки відповідають одній інструкції LEA x86, тому це надзвичайно швидко.

Насправді, множення з ще більшим простим рівнем 73 можна було зробити з однаковою швидкістю, встановивши y := x + 8 * x; z := x + 8 * y.

Використання 73 або 37 (замість 31) може бути кращим, оскільки це призводить до більш щільного коду : Дві інструкції LEA беруть лише 6 байт проти 7 байтів для переміщення + shift + віднімання для множення на 31. Один з можливих застережень: 3-аргументаційні інструкції LEA, використані тут, стали повільнішими в архітектурі Sandy Bridge від Intel, зі збільшенням затримки на 3 цикли.

Більше того, 73 - це улюблене число Шелдона Купера.

Ніл Коффі пояснює, чому 31 використовується при прасуванні зміщення .

В основному використання 31 дає більш рівномірний розподіл ймовірностей для хеш-функції.

З JDK-4045622 , де Джошуа Блох описує причини, по яких String.hashCode()було обрано саме цю (нову) реалізацію

У таблиці нижче наведено ефективність різних хеш-функцій, описаних вище, для трьох наборів даних:

1) Усі слова та фрази із записами у 2-му міжнародному слові Мерріам-Вебстер (311,141 рядки, середня довжина 10 символів).

2) Усі рядки в / bin / , / usr / bin / , / usr / lib / , / usr / ucb / та / usr / openwin / bin / * (66,304 рядків, середня довжина 21 символу).

3) Список URL-адрес, зібраних веб-сканером, який працював упродовж декількох годин минулої ночі (28 372 рядка, середня довжина 49 символів).

Показник продуктивності, показаний у таблиці, - це "середній розмір ланцюга" над усіма елементами хеш-таблиці (тобто очікуване значення кількості ключів порівнюється з пошуком елемента).

                          Webster's   Code Strings    URLs
                          ---------   ------------    ----
Current Java Fn.          1.2509      1.2738          13.2560
P(37)    [Java]           1.2508      1.2481          1.2454
P(65599) [Aho et al]      1.2490      1.2510          1.2450
P(31)    [K+R]            1.2500      1.2488          1.2425
P(33)    [Torek]          1.2500      1.2500          1.2453
Vo's Fn                   1.2487      1.2471          1.2462
WAIS Fn                   1.2497      1.2519          1.2452
Weinberger's Fn(MatPak)   6.5169      7.2142          30.6864
Weinberger's Fn(24)       1.3222      1.2791          1.9732
Weinberger's Fn(28)       1.2530      1.2506          1.2439

Переглядаючи цю таблицю, зрозуміло, що всі функції, за винятком поточної функції Java та двох розбитих версій функції Вайнбергера, мають чудову, майже нерозрізнену продуктивність. Я напевно здогадуюсь, що ця ефективність є по суті "теоретичним ідеалом", що ви отримаєте, якби замість хеш-функції використали справжній генератор випадкових чисел.

Я би виключав функцію WAIS, оскільки її специфікація містить сторінки випадкових чисел, а її продуктивність не краща за будь-яку з набагато простіших функцій. Будь-яка з решти шести функцій здається чудовим вибором, але ми повинні вибрати одну. Я вважаю, що я би виключив варіант Во та функцію Вайнбергера через їх додаткову складність, хоч і незначну. З решти чотирьох я, мабуть, обрав би P (31), оскільки це найдешевший підрахунок на машині RISC (адже 31 - різниця двох потужностей двох). P (33) аналогічно дешевий для обчислення, але його продуктивність незначно гірша, а 33 - композитний, що робить мене трохи нервовим.

Джош

Блох не дуже впадає в це, але обґрунтування, яке я завжди чув / вважав, - це основна алгебра. Хеши зводяться до операцій множення та модуля, а це означає, що ви ніколи не хочете використовувати числа із загальними факторами, якщо зможете в цьому допомогти. Іншими словами, порівняно прості числа забезпечують рівномірний розподіл відповідей.

Номери, що складаються за допомогою хеша, зазвичай:

• модуль типу даних, який ви вводите в нього (2 ^ 32 або 2 ^ 64)
• модуль кількості відра у вашому хеш-файлі (варіюється. У java раніше був простим, зараз 2 ^ n)
• помножити або змістити на магічне число у вашій функції змішування
• Вхідне значення

Ви дійсно отримаєте можливість контролювати лише пару цих значень, тому трохи додаткової обережності.

В останній версії JDK досі використовується 31. https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#hashCode ()

Призначення хеш-рядка:

• унікальний (Дозвольте побачити оператора ^в документі обчислення хеш-коду, він допоможе унікальним)
• дешева вартість розрахунку

31 - це максимальне значення, можна ввести 8-розрядний (= 1 байт) регістр, найбільше просте число можна помістити в 1 байт-регістр, непарне число.

Помножте 31 - це << 5, тоді відніміть себе, тому потрібні дешеві ресурси.

Я не впевнений, але я б припустив, що вони протестували деяку вибірку простих чисел і виявили, що 31 дає найкращий розподіл по деякій вибірці можливих рядків.

Це тому, що 31 має хорошу властивість - його множення може бути замінено побітовим зсувом, який швидше, ніж стандартне множення:

31 * i == (i << 5) - i