Не 'международный GetHashCode', немного близорукий?
Учитывая, что .NET имеет способность обнаружить разрядность через IntPtr (просматривающий отражатель, хорошая сумма его отмечена небезопасная, хотя - позор) я думал, что GetHashCode, возвращая интервал потенциально близорук.
Я знаю, что в конечном счете с хорошим алгоритмом хеширования миллиарды перестановок, предлагаемых Int32, абсолютно соответствуют, но несмотря на это, чем более узкий возможный набор хешей, тем медленнее хешированные ключевые поиски как больше линейного поиска, будет требоваться.
Одинаково - я единственный, кто находит это забавным:
struct Int64{
public override int GetHashCode()
{
return (((int) this) ^ ((int) (this >> 0x20)));
}
}
Пока Int32 просто возвращается this.
Если IntPtr исключен из-за проблем производительности, возможно, IHashCode, который реализует IEquatable и т.д., лучше?
Поскольку наши платформы становятся более крупными и больше с точки зрения емкости памяти, размер диска и т.д., конечно, дни хешей на 32 бита, являющихся достаточно, потенциально сочтены?
Или это просто имеет место, что издержки, вовлеченные или в абстрагирующий хеш через интерфейсы или в адаптирующий размер хеша согласно платформе, перевешивают какие-либо потенциальные выигрыши в производительности?
2 ответа
Хэш-функция Int64 существует для того, чтобы убедиться, что все биты учтены - так что в основном это XORing верхних 32 бит с нижними 32 битами. Лучше общего назначения представить не могу. (Усечение до Int32 было бы нехорошо - как же тогда корректно иметь 64-битные хэш-значения, у которых все нули в младших 32 битах?)
Если бы в качестве возвращаемого значения хэша использовался IntPtr, то код должен был бы иметь условные ветви (32-битные? 64-битные? и т.д.), которые бы замедляли работу хэш-функций, одолевая весь смысл.
Я бы сказал, что если у вас есть хэш-функция, которая на самом деле имеет 2 миллиарда ведер, то вы, скорее всего, все равно находитесь на этапе написания целой пользовательской системы. (Возможно, база данных была бы лучшим выбором?) При таком размере, обеспечение равномерного заполнения ведер было бы более насущной задачей. (Другими словами, лучшая хэш-функция, вероятно, принесла бы больше дивидендов, чем большее количество ведер).
Ничто не помешало бы реализовать базовый класс, у которого была бы эквивалентная 64-битная хэш-функция, если бы вы хотели иметь в памяти многогигабайтную карту. Однако вам придется написать свой собственный словарный эквивалент.
Вы понимаете, что хэш-код, возвращенный GetHashCode, используется для обращения в хеш-таблице? Используя больший тип данных было бы бесполезное упражнение, так как все хеш-таблицы меньше так или иначе. Дополнительная информация была бы просто потрачена впустую, потому что она не может использоваться соответственно.
Общие хеш-таблицы имеют в порядке нескольких тысяч к нескольким миллионам записей. Целое число на 32 бита более, чем достаточно для покрытия этого диапазона индексов.