Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Сказанное понял, но вот в чем тут проблема. Мы говорим о... 11.12.06 01:15 Число просмотров: 5433
Автор: MadBinom Статус: Незарегистрированный пользователь
|
> 64-битная hash-функция, в случае её применения для
> построения ассоциативных hash-таблиц, может выиграть у
> 32-битной только когда размер "плоской" части таблицы
> приблизится или превзойдёт 2^32. В свою очередь, такой
> размер таблицы будет оправдан, только когда кол-во входов
> приблизится к 2^31. В реальной жизни таких наборов данных
> очень не много, для их обработки таким способом нужно как
> минимум несколько десятков мегабайт RAM.
Сказанное понял, но вот в чем тут проблема. Мы говорим о хеш-функциях для построения, например, строковых пулов и прочего, требующего именно скорости(ведь говорилти о хеш для строк). Такие хэш функции обладают очень плохими показателями по поводу коллизий. Поэтому рассмотрим 2 варианта, строковой пул большой(сказано грубо конечно, но да ладно, смысл разделения на 2 ситуации прояснится в подпунктах) или маленький.
1.Пул маленький
Коллизий немного как у 32-х так и у 64-х функций.
Скорость у 32-х разрядных меньше чем у 64-х разрядных.(учитывая 64х архитектуру)
Памяти примерно в 2 раза(тк коллизий мало) больше ест 64-разрядная реализация.Но ведь пул небольшой.
2.Пул большой.
Коллизий много больше у 32-х чем у 64-х функций.
Скорость у 32-х разрядных меньше чем у 64-х разрядных.(учитывая 64х архитектуру)
Памяти много больше ест 64-разрядная реализация(много больше так как строк много), но это ПОЧТИ всегда единственный выход - так как тут у нас резкое падение производительности при использовании 32-х функций, так как много у них коллизий.
|
|
|
подробно о проекте
Анализ криптографических сетевых... 
