Comments 9
Спасибо за интересную статью, но не могу не придраться:
или объем занимаемой контейнером оперативной памяти (в Мбит или Кбит — см. подписи на графиках).
Не в Мбит/Кбит, а в обыденных мега/кило, то есть, в миллионах и тысячах, но байт.
классно спасибо) интересно как они поведут себя там где им место в вокселях(пишу так потомучто 6 граней подразумеваю от центроида по логике отрисовки тоже вокселем), там вся последовательность плоская, я на векторе делал), со всеми оптимизациями(воксельными)) там вообще класс выходит
получается в bvh их тоже можно использовать вроде, надо же только пробежаться ) надо тестить )
Спасибо за статью. Было бы ещё здорово сравнить с std::pmr контейнерами c
monotonic_buffer_resource.
Так pmr это всё те же контейнеры, у них только аллокаторы другие используются. При желании вы и flat_map можете сделать pmr, там перф подрастает по другой причине
Да. Благодаря чему обычные map set становятся cache friendly. И казалось бы время поиска/вставки/... тоже должны уменьшиться. Но надо бенчить
Оно и уменьшается, но на определенных размерах и условиях, и происходит это большей частью из-за того, что данные для работы почти всегда находится в кеше и не надо идти в ram, минус время на алокации (вот тут если интересно подробнее). И как вы правильно подметили, сначала профайлер, потом изменения
Мы заменяли обычный map на flatmap (из Abseil) после того, как я наблюдал деструктор map, который работал 10 минут и при этом ещё блочил все остальные потоки приложения, если они пытались что-то сделать с памятью.
Замена на flat map привела к ускорению и экономии памяти что-то там в сотни раз по всему алгоритму, пауза на освобождение памяти тоже исчезала. Скорость вставки в чистом виде не замерялась, так как там ещё некоторая логика есть для вычисления что вставлять, включая чтение из базы, поэтому так просто не выделить вклад именно хеша. Но мне кажется на искусственных тестах вставка тоже быстрее была.
Так что рекомендую, при больших объемах данных.
Логично, что flat версия тогда профитна, когда размер элемента со всеми вспомогательными полями кратно меньше размера кэш линии. Это заметно повышает шанс, что несколько элементов буду отпроцессены из одной кеш линии. Если размер элемента больше кеш линии, то уже в целом плевать где там в памяти раскиданы элементы, так все равно попадаем на чтение новой кеш линии, и вероятный поход в оперативку. Следующий порог по перфу - это когда элемент уже больше страницы памяти, т.е больше 4кб. Тогда мы ещё к промаху по кешу прибавляем вероятный промах по кешу TLB, тк он вовсе не резиновый. Но удаление flat контейнера будет однозначно быстрее при любом размере.
Плоские контейнеры в C++23