Замедлит ли динамическое распределение в другом потоке мой основной поток обработки?

#c #multithreading #performance #low-latency

#c #многопоточность #Производительность #низкая задержка

Вопрос:

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

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

Повлияет ли присутствие этого другого потока, выполняющего динамическое распределение, на мой критический поток?

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

2. Хороший момент. Я предполагаю, что динамически выделяемая память окажет большее влияние на кеш, чем если бы объекты находились в стеке.

3. Кроме того, иногда не очевидно предсказать, когда (и в каком потоке) динамическое распределение действительно произойдет. Возможно, стоит перепроверить, действительно ли критический поток свободен от динамического распределения (например, копирование строки при записи)

4. Два потока по-прежнему используют одну и ту же кучу. Динамическое распределение приводит к фрагментации кучи, что замедляет выделение / освобождение.

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

Ответ №1:

Определенно, да.
Не только для косвенного влияния на расположение памяти и уничтожение L3, но и для немедленного эффекта время от времени.
Когда вызывается malloc, он пытается повторно использовать то, что уже было выделено и освобождено, но иногда приходится расширять пространство памяти процесса, и он делает это, вызывая mmap или brk .
Я не уверен на 100% насчет brk, но mmap определенно делает недействительным TLB, поэтому вы должны ожидать более медленной обработки ошибок страницы сразу после этих вызовов.
Если вы используете Linux или * BSD, вы можете попробовать поработать с кодом ядра, чтобы не приводить к недействительности во всех случаях, но не ожидайте, что это будет просто.

1. Эффекты системного вызова являются одноразовыми эффектами: как только пространство виртуальной памяти достигнет максимального размера, больше не будет сбросов TLB. Поскольку используется привязка к процессору, также не будет более значительного разгрома L3, чем создаст любой другой поток. Поскольку OP заявляет, что критический по времени поток не выделяет никакой памяти, прямая задержка не вводится с помощью malloc() вызовов. Но, как всегда с производительностью, истина заключается только в измерении.