Как работает масштабируемый_аллокатор Intel TBB?

Что на самом деле делает tbb::scalable_allocator в строительных блоках Intel Threading Building Block?

Это, безусловно, может быть эффективным. Я только что использовал его, чтобы сократить время выполнения приложений на 25% (и увидеть увеличение использования ЦП с ~ 200% до 350% в 4-ядерной системе), изменив один std::vector<T> на std::vector<T,tbb::scalable_allocator<T> >. С другой стороны, в другом приложении я видел, как оно удваивает и без того большое потребление памяти и отправляет вещи в город подкачки.

Собственная документация Intel не дает много информации (например, короткий раздел в конце этого Часто задаваемые вопросы). Может ли кто-нибудь сказать мне, какие трюки он использует, прежде чем я сам пойду и покопаюсь в его коде?

ОБНОВЛЕНИЕ: я впервые использую TBB 3.0 и вижу лучшее ускорение от scalable_allocator. Замена одного vector<int> на vector<int,scalable_allocator<int> > сократила время выполнения чего-либо с 85 до 35 с (Debian Lenny, Core2, с TBB 3.0 после тестирования).


c++ multithreading malloc stl tbb
person timday    schedule 18.03.2009    source источник

Ответы (2)


arrow_upward
20
arrow_downward

По распределителю есть хорошая статья: Основы масштабируемого многоядерного программного обеспечения в строительных блоках Intel Threading Building Blocks

Мой ограниченный опыт: я перегрузил глобальное новое/удаление с помощью tbb::scalable_allocator для своего приложения ИИ. Но изменения во временном профиле были незначительными. Однако я не сравнивал использование памяти.

person amit    schedule 19.03.2009
comment
Спасибо! Статья содержит именно ту информацию, которую я искал. - person timday; 19.03.2009
comment
Исходная ссылка больше не работает, но у CiteSeer есть PDF-файл: citeseerx .ist.psu.edu/viewdoc/summary?doi=10.1.1.71.8289 - person Arto Bendiken; 04.04.2013
comment
Чтобы добавить точку данных: в моем конкретном приложении конкуренция за аллокатор останавливала ускорение примерно на 15 потоках, после этого он убивал все ускорение, а к 40 он был бы намного медленнее, чем однопоточный. При использовании scalable_allocator во внутренних ядрах для каждого потока узкое место исчезло, и ожидаемое масштабирование вернулось. (машина имеет 40 физических ядер). - person Adam; 04.05.2014

arrow_upward
3
arrow_downward

Упомянутое вами решение оптимизировано для процессоров Intel. Он включает в себя специальные механизмы ЦП для повышения производительности.

Некоторое время назад я нашел еще одно очень полезное решение: Быстрый распределитель C++11 для контейнеров STL. Это немного ускоряет контейнеры STL на VS2017 (~5x), а также на GCC (~7x). Он использует пул памяти для размещения элементов, что делает его чрезвычайно эффективным для всех платформ.

person no one special    schedule 05.11.2017