DarkPhoenix

Да это пик социолизации нравиться он нам или нет.

В разных условиях / игровых правилах разные пики социализации. Во фронтире может сложиться так, что пик будет в разы меньше (например, группы крупнее 50 не смогут получить достаточно преимуществ чтобы быть во всем круче групп меньше 50, но при этом лучше чем 50 одиночек). Почему пики ограничиваются вариантами или 1, или 5000 - я не понял.

happy one?
нойзер, хозе, хедкандир, браункелтир, плюша иже вспомнят

happy one ни о чем мне не говорит (может быть и был когда-то у него такой ник где-то). Но да, келтир, хозе, плюша (и ммуту, который уже пару лет как от рака помер) из той тусы, да. А ника и хед вроде как нет.

eve in-game был happy vozzic, zkb чет не але

https://zkillboard.c...cter/296009786/ вот его мейн, по сути это чат экс-gcc (корпа хаарта) и прилипшие друзяшки

Основной массив в котором все эти бакеты лежат и на размер которого делится ключ, или хэш ключа, я хз как он правильно называется. Не знаю как он в расте реализован, в дотНете он по-умолчанию простое число, ибо интегеры хранятся и распределяются как есть, без хэширования, а в джаве уже не заморачивались, тупо степень двойки. Хотя много лет назад этим интересовался, все мог позабыть.

Про имплементации в C# и джаве читал когда с темой разбирался, да (и про то что в некоторых языках если ключи инты, то nohash используется по умолчанию). Но SwissTable'у нужна хэш-функция с хорошим распределением получаемых значений по всему множеству возможных значений, иначе... ну, будет то что у меня, падение производительности на вставках раз в 5. Переключаться с него на что-то другое пока что не намерен, если будет время свободное от всего остального то мб поковыряюсь, но явно не в этом году

Насколько я помню, нохэш с нерандомными уникальными ключами тоже могут норм работать, надо только массив делать не круглым размером, типа 10000 элементов, а размером с простое число, тогда будет распределено более равномерно.

Массив чего? То что бакетом называется? У меня стандартная растовая хэшмапа (порт гуглового SwissTable'а) под который я подбираю хэш, а не имплементацию хэшмапы под алгоритм хэша или имплементацию + алгоритм хэша под задачу. Переделывать саму имплементацию я не хочу т.к. выхлопа минимум за кучу усилий, в отличие от подбора алгоритма хэша под всякие-разные сценарии.

Пару-тройку месяцев назад в своей вычислительной библиотеке (для евы) пробовал разные оптимизации, в т.ч. разные алгоритмы хеширования, т.к. всякие структуры данных с хешированием используются очень активно. Столкнулся с тем, что no-hash алгоритм был медленнее fxhash'а/ahash'а даже для примитивных ключей, которые по определению уникальны (u64), что с моим пониманием того как работают хэшмапы было нонсенсом. Поэкспериментировал с разными ключами (рандом / последовательность / рандом по части множества), понял что для рандом ключей нохэш хорошо заходит, а для последовательных он супертормозной.
 
Спросил в чате знакомых погромистов-выходцев из евы. Знакомый (воззик с этого форума, щас наверное никто и не вспомнит) натренированный "под себя" дипсик спросил, получился такой ответ (много мата):

И по сути ответ получил, и стилистика выдержана неплохо (пусть много кому и не зайдет). В общем, весьма впечатляюще, как по мне.