Особенности памяти при многопоточности

Question

Я реализую алгоритм на C / C ++ для обработки некоторых векторов, и я подумал, что было бы неплохо сделать его параллельным, поскольку я работаю с многоядерным процессором. У меня есть некоторый опыт работы с GPGPU, и там плохой доступ к памяти может испортить всю производительность. Нужно ли учитывать какую-то особую схему доступа между ядрами на ЦП?

Спасибо

Answer 1

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

Необходимо примерно знать размер строки кэшана вашем ящике и попробуйте 2 вещи:

1. Ограничьте количество строк кэша данных (в частности, строк кэша, в которые вы пишете), доступных в короткой временной последовательности одним потоком.То есть, избегайте «загрязнения» большего количества строк кэша, чем нужно.
2. Избегайте, как чума, когда два отдельных потока «одновременно» обращаются к одной и той же строке кэша данных при одной записи.* (Приведенные выше два правила также применяются к страницам данных, если вы имеете дело с большими структурами данных, которые должны быть разбиты на страницы.)

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

Answer 2

@ Hot_Licks: На самом деле, если потоки - это две гиперпотоки, работающие на одном и том же ядре, то нет проблем с доступом к ним разных потоков в режиме чтения или записи.Чистые линии распределяются бесплатно между аппаратными потоками на одном и том же процессоре Intel.Даже грязные строки передаются очень дешево - хотя вы можете получить MOnukes, если один парень читает данные одновременно, а другой пишет.(Как ни странно, без штрафа, если два таких аппаратных / гиперпотока пишут одновременно.)

С единственным «поточным» процессором AMD, Bulldozer, я думаю, что совместное использование записи еще дешевле.

Но это относится только к аппаратным потокам, например, гиперпотокам Intel или логическим процессорам, работающим на тех же физических процессорах.Если они работают на разных физических процессорах, победа не будет.Поскольку большинство программных потоковых потоков переносят потоки произвольно, ваше правило не так уж плохо.

Тем не менее, вы все равно хотите свести к минимуму (а) строки, к которым обращается один поток, и (б) общее количество строк, к которым обращается несколькотемы, даже если они не разделены другими потоками.Так как кеши - MLC, LLC - это ограниченный ресурс.Но вы правы - как только вам не хватает кеша ...