memory_pool questions

[Popov__Maxim]

Добрый день!

Тут же можно писать по-русски?

Вопрос по tbb::memory_pool. Мы очень заинтересованы в использовании этого класса в нашем продукте, уже получены реальные достижения в ускорении и т.п.

Посему возникло несколько вопросов:

1. memory_pool уже долгое время в виде preview фичи. Нам не очень хочется использовать в коммерческом продукте "сырые" preview инструменты. Планируется-ли выпустить memory_pool в релизном статусе?

2. в настройках memory_pool я нашёл возможность, чтобы pool не отдавал память обратно в систему после вызова free. Нам эта возможность крайне полезна, однако я не могу ею воспользоваться без редактирования файлов tbb (чего очень не хочется делать). Можно-ли как-то включить эту возможность без редактирования файлов? Неплохо бы иметь эту возможность в интерфейсе memory_pool

3. Так же есть несколько пожеланий: больше возможностей по контролю и мониторингу памяти, например принудительный сброс в систему неиспользуемых страниц. получение статистики: сколько объектов сейчас саллокировано в memory_pool, их суммарный размер, а так же сколько системной памяти потребляет pool в данный момент. Возможно ещё что-то, но это уже не так важно.

С уважением,

Максим Попов

[Alexey-Kukanov]

Здравствуйте, Максим.

Насколько я понимаю, писать можно на любом языке; вопрос в том, ответят ли :) С русским в этом плане проблем быть не должно.

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

Возможность не отдавать память обратно используется в классе fixed_pool. Или вам интересен растущий пул, который тем не менее не возращает память? 

В целом, было бы полезно узнать больше о том, как вы используете пулы. Если вы не хотите публиковать подобную информацию на форуме, дайте знать, и мы свяжемся с вами приватно.

[Popov__Maxim]

Спасибо за ответ!

Я заметил, что есть ограничение на общее число memory_pool-ов. А каково это ограничение в цифрах, сколько пулов можно создать?

Да, нам именно интересен растущий пул, но с возможностью не отдавать память. fixed_pool не подходит по той причине, что нам заранее неизвестен необходимый размер памяти. Существующий код достаточно сложен, чтобы точно подсчитать необходимый размер памяти.

Вкратце - в нашем приложении используются только классические malloc-realloc-free-new-delete. И в некоторых местах добавлена оптимизация на основе tbb::scalable_allocator. Однако аллокаций и освобождений много, всё это приводит к фрагментации памяти и долгой работе стандартных malloc-free. Так же мы столкнулись с тем, что операционная система долго выделяет физическую память для процесса, в особенности это стало заметно на Windows Server, именно поэтому мы хотим использовать пулы, которые не возвращают память в систему (либо возвращают только по явному запросу).

Как я уже писал выше, код сложный и объёмный, сильно менять алгоритм не хочется. Поэтому на первом этапе я хочу разделить аллокации как минимум на два блока: временная память и более долгоживущие объекты. И под них выделить разные пулы, чтобы устранить фрагментацию. Довольно частый паттерн - создание временного объекта, создание "постоянного объекта", освобождение временного объекта. И такие алгоритмы зачастую запускаются в параллели, что ещё более ухудшает фрагментацию.

В дальнейшем есть мысли и планы по ещё более глубокой оптимизации на основе пулов.

Так же было бы интересно иметь какой-то контроль над областями выделения памяти, с целью оптимизации NUMA. И вообще был бы интересен функционал по работе с NUMA в TBB.

Если вас интересуют более подробные детали - напишите свою почту, расскажу.

Максим