'new' и 'delete' не так масштабируемы как строительный блок потоков Intel scalable_malloc / free

Question

Для ясности, это не реклама библиотеки tbb. просто то, что я недавно обнаружил, что очень удивило меня.

Я сделал небольшой гугл на кучу споров. и похоже что после glibc 2.3. 'new' и 'delete' были улучшены для поддержки мультипроцессоров очень хорошо. мой glibc 2.5. и для следующего очень простого кода.

tbb::tick_count t1 = tbb::tick_count::now();

    for (size_t i = 0; i < 100000; ++i)
    {
        char * str = new char [100];
        delete str;
    }
tbb::tick_count t2 = tbb::tick_count::now();
std::cout << "process time = " << (t2 - t1).seconds() << std::endl;

Я получил коробку Linux с 16 ядрами процессора. и я запустил 1 и 8 потоков, соответственно, для запуска вышеуказанного кода. Первое, что меня поразило, это то, что время обработки меньше, когда запущено 8 потоков. это не имело смысла для меня. как это вообще возможно?

Другой тест, который я сделал, состоит в том, что вместо простого кода каждый поток выполняет довольно сложный алгоритм, во время алгоритма есть довольно много новых и удаляемых тоже. и хотя число потоков увеличилось с 1 до 8, время обработки почти увеличилось на 100%.

Вы можете спросить, как я узнал, что «new» и «delete» вызвали увеличение времени, потому что после того, как я заменил «new» и «delete» на tbb scalable_malloc / free, время обработки увеличилось только примерно на 5 %, когда номер потока был увеличен с 1 до 8.

вот еще одна загадка для меня, почему «new» и «delete» не масштабируются так же, как в предыдущем простом коде.

Другая загадка заключается в том, что если я добавлю предыдущий простой код в начало алгоритма, который запускает каждый поток. тогда не было никакого увеличения времени, пока я увеличивал номер потока с 1 до 8.

Я был так удивлен моим тестом. Может ли кто-нибудь дать объяснение результатов моего теста? Большое спасибо здесь.

Answer 1

Это совсем не загадка.Хорошо известно, что при распределении памяти в многопоточных приложениях увеличивается время блокировки потоков (в частности, это происходит для спящих потоков в состоянии ядра TASK_UNINTERRUPTIBLE в Linux).А выделение памяти из кучи может быстро стать узким местом, поскольку стандартный распределитель обрабатывает множественные запросы на выделение из нескольких потоков путем сериализации запросов.Это основные причины ухудшения характеристик, которые вы испытываете.Конечно, это в свою очередь приводит к внедрению эффективных распределителей.Вы упомянули TBB, но есть и другие свободно доступные альтернативы.

См., Например, библиотеку ThreadAlloc , которая, как сказал его автор, "обеспечивает производительность примерно в 10 раз выше"сравнение со стандартным распределителем на платформах SMP для многопоточных приложений, интенсивно использующих динамическое выделение памяти ".

Другой вариант - Hoard .