Hokum 31 авг 2018 в 08:48

OutOfLine – паттерн размещения в памяти для высокопроизводительных приложений на C++

5 мин

8.8K

Высокая производительность*C++*

Перевод

+37

Комментарии 33

svr_91 31 авг 2018 в 11:14

А зачем использовать unique_ptr в map? Нельзя просто класть данные по типу?

Hokum 31 авг 2018 в 11:30

Для большей гибкости, так как в общем случае тип ColdData может быть не перемещаемым и не копируемым.

svr_91 31 авг 2018 в 11:36

Такие типы довольно хорошо в мапу ложаться. Для этого можно использовать

m.emplace(std::piecewise_construct, ...)

Hokum 31 авг 2018 в 11:54

А как их перемещать при перемещении основного объекта?

svr_91 31 авг 2018 в 12:10

Ну, если ColdData не поддерживает перемещение, то может и не поддерживать перемещение основного объекта? Хотя да, об этом я не подумал

Antervis 31 авг 2018 в 20:15

мапе ж не нужно перемещать/копировать объекты, достаточно сравнивать, емплейсить ну и удалять

-2

Prototik 1 сен 2018 в 00:56

Да правильно, нахрена что-то получать из мапы — достаточно добавлять и удалять.

Antervis 1 сен 2018 в 12:52

«получать из мапы» можно и по ссылке. Разумеется, подумав о владении

НЛО прилетело и опубликовало эту надпись здесь

Hokum 1 сен 2018 в 10:17

Здорово! Жаль, что GCC только начиная с 7.1 это поддерживает.

maydjin 31 авг 2018 в 12:20

А доступ к элементам мэп не защищён блокировками потому, что… ?

Kobalt_x 31 авг 2018 в 12:31

потому что блокировки в такой ситуации(вычислительно-интенсивном алгоритме), при большом количестве потоков ещё большее зло, Если уж радеем за каждый flops то уж лучше concurrent_unordered_map из tbb

-1

maydjin 31 авг 2018 в 12:38

Ну чего лучше это понятно. Вопрос почему автор об этом не сказал ни слова. В любом случае *concurent*map* from *.h* обычно стоит таки не бесплатно, т.к. потокобезопасность не волшебными гномиками достигается. Соответственно, автор либо показал не всё решение, либо его бенчмарк не отражает картину в целом, либо в реализации есть банальная ошибка. Либо не описал ограничения подхода.

Я своими глазами видел в горячем mission critical коде подобный подход с доступом к мапе без блокировки, и как ни странно, он работал годами, ну иногда баги там какие то странные всплывали раз в полгода...

Hokum 31 авг 2018 в 12:56

Возможно в их случае это не нужно, например, все объекты создаются в одном потоке при старте программы, и уничтожаются в том же потоке при завершении. Доступ к «холодным» данным осуществяется только в исключительных случаях, которые могут обрабатываться том же потоке, где и были созданы (мало ли как у них построена система).

Так как подразумевается, что доступ к «холодным» данным явление редкое, то добавление блокировок не сильно уменьшит производительность, а параллелится, скорей всего обработка массивов с «основными» данными.

maydjin 31 авг 2018 в 13:32

Вот эти слова с ограничениями хотелось бы видеть в статье или в переводе. Можно например у авторов спросить — как так?

RPG18 31 авг 2018 в 12:41

Может быть у них все работает в одном потоке?

maydjin 31 авг 2018 в 12:42

Тогда, считать наносекунды на фоне i/o слегка странно.

RPG18 31 авг 2018 в 12:45

Согласен, что пример неудачный, но подход то рабочий.

maydjin 31 авг 2018 в 12:47

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

RPG18 31 авг 2018 в 12:58

Блокировки будут при создании/удалении элементов, которые лежат в векторе. Это тоже накладывают нюансы. А оптимизация на одном потоке при i/o не такая уж и редкая задача. Однопоточные сервисы никуда не делись.

maydjin 31 авг 2018 в 13:25

Я скорее к тому, что распараллеливание такого сервиса даст более драматичный прирост производительности. И тогда, остаётся только кейс с одно ядерными системами, что довольно редко в наше время. Второй момент — речь идёт о поддержании чистоты кэша, но, если на этом же ядре будет происходить ввод/вывод то все потуги со структурами массивов кажутся каплей в море ибо кэшем будет в общем то заправлять ядро. Т.е. для одноядерного сценария с i/o, лично мне, это кажется оптимизацией уровня писать на асме вместо C.

RPG18 31 авг 2018 в 13:53

Насколько понимаю, разработчики tarantool стараются оптимизировать расположения элементов в памяти.

maydjin 31 авг 2018 в 14:03

Я опыта с этой поделкой не имел, но по описанию в интернете это in memory database? Там i/o сильно условный и в юзерспейсе происходит нет?

a-tk 31 авг 2018 в 13:53

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

maydjin 31 авг 2018 в 14:04

Звучит разумно.

Videoman 31 авг 2018 в 13:23

Кроме многопоточности, автор, также, ничего не говорит о UB в случае использования таких «волшебных» объектов совместно с другими глобальными объектами, т.к. порядок их создания и разрушения не определен. На мой взгляд, тут на лицо проблема архитектуры классов, когда в обертку файлового дескриптора, зачем-то, запихнули path, который не используется 90% времени, а может быть вообще не применим к такому объекту. В этом случае, я бы рекомендовал создать мапу явно, если она нужна, и работать с ней отдельно от обертки, которая вполне себе самодостаточная сущность, на мой взгляд. В общем, такое решение, как «затычка» в конкретной ситуации, может быть и имеет право на жизнь, но паттерном я бы такой подход не стал называть.

maydjin 31 авг 2018 в 13:28

Точно, композиция лучше и агрегации и наследования, почти всегда. Вот если бы пул для холодных данных можно было бы задавать из вне, было бы интереснее.

ilammy 31 авг 2018 в 15:47

Мне интересно, зачем понадобилось держать все эти файлы в файловой системе? Ведь файлы можно открыть, получить дескриптор, и тут же удалить: файл будет жить до последнего закрытого файлового дескриптора. В Linux ещё есть O_TMPFILE, с помощью которого можно избежать выдумывания имени для файла. При необходимости другие процессы могут получить доступ к таким файлам через procfs (или её аналог). Через неё же файл можно вернуть в файловую систему, если потребуется.

Hokum 31 авг 2018 в 18:54

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

mayorovp 31 авг 2018 в 18:58

Мне кажется, API можно сильно упростить если вместо ColdData& выставлять наружу std::unique_ptr<ColdData>&.

В частности, пропадут TwoPhaseInit, init_cold_data и reset_cold_data

iperov 31 авг 2018 в 20:56

после 15 лет кодинга на С++, я уже не могу на него смотреть. А динозавры всё еще придумывают новые способы как прострелить себе ногу. Холодные, горячие, бред.

-9

Fedcomp 1 сен 2018 в 11:57

Что думаете о Rust?

voidnugget 1 сен 2018 в 03:38

Такой же принцип используется в golang'e, только там ещё буфера (структуры) сортируются по частоте обращений — возможно будет полезно для вашего случая, так как там получается даже более чем в 10 раз быстрее.

-1

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

OutOfLine – паттерн размещения в памяти для высокопроизводительных приложений на C++

Комментарии 33

Публикации

Истории