LINUX.ORG.RU

История изменений

Исправление bugfixer, (текущая версия) :

Основная разница в том что тут юзается std::unordered_map c которым я толком дела не имел в параллельных задачах.

Любые STD containers требуют внешней синхронизации. Я вообще удивлён что оно не развалилось как карточный домик ещё….

Еще один вопрос - есть ли какие то рекомендации по выбору числа бакетов? Я выбрал порядка числа элементов (на два порядка ниже чем диапазон ключей), стало лучше чем по умолчанию. Сейчас еще поиграюсь конечно, но боюсь дело совсем не в этом…

Нужно собирать статистику. Например у меня на одном очень легко нагруженном инстансе в проде:

stats: count=2053 load=0.140283 maxSize=2 avg=1.08271 avg2=1.15278
index: [0:1787, 1:244, 2:22]

А вот пример с одного из наиболее нагруженных:

stats: count=467341 load=0.297126 maxSize=6 avg=1.16456 avg2=1.31482
index: [0:1171565, 1:342145, 2:52883, 3:5718, 4:516, 5:40, 6:2]

Задача - добиться чтобы «хвост» (число collisions) не был длинным.

P.S. У нас что gcc что boost довольно старенькие - на них boost::hash_map более «агрессивен» чем std::unordered_map, и при прочих равных выигрывает. Хозяйке на заметку.

Исходная версия bugfixer, :

Основная разница в том что тут юзается std::unordered_map c которым я толком дела не имел в параллельных задачах.

Любые STD containers требуют внешней синхронизации. Я вообще удивлён что оно не развалилось как карточный домик ещё….

Еще один вопрос - есть ли какие то рекомендации по выбору числа бакетов? Я выбрал порядка числа элементов (на два порядка ниже чем диапазон ключей), стало лучше чем по умолчанию. Сейчас еще поиграюсь конечно, но боюсь дело совсем не в этом…

Нужно собирать статистику. Например у меня на одном очень легко нагруженном инстансе в проде:

stats: count=2053 load=0.140283 maxBuckets=2 avg=1.08271 avg2=1.15278
index: [0:1787, 1:244, 2:22]

А вот пример с одного из наиболее нагруженных:

stats: count=467341 load=0.297126 maxBuckets=6 avg=1.16456 avg2=1.31482
index: [0:1171565, 1:342145, 2:52883, 3:5718, 4:516, 5:40, 6:2]

Задача - добиться чтобы «хвост» (число collisions) не был длинным.

P.S. У нас что gcc что boost довольно старенькие - на них boost::hash_map более «агрессивен» чем std::unordered_map, и при прочих равных выигрывает. Хозяйке на заметку.