Банк конфликтов из-за непоследовательного доступа в общей памяти на CUDA - PullRequest
Новая
       19

Банк конфликтов из-за непоследовательного доступа в общей памяти на CUDA

0 голосов
/ 07 января 2020

Я нахожусь в процессе написания некоторого кода симуляции N-тела с короткими взаимодействиями в CUDA, ориентированном на карты серий Вольта и Тьюринга. Я планирую использовать разделяемую память, но мне не совсем понятно, как при этом избежать банковских конфликтов. Поскольку мои взаимодействия локальны, я планировал отсортировать данные частиц по локальным группам, которые я могу отправить в общую память каждого SM (пока не беспокоиться о частицах, у которых есть сосед, над которым работает другой SM. Для того, чтобы получить хорошее производительности (исключая конфликты банков), достаточно ли того, чтобы каждый поток считывал / записывал с / на другой адрес разделяемой памяти, но каждый поток мог обращаться к этой памяти не последовательно без штрафа?

Вся информация Кажется, я только упоминаю, что память должна быть объединена для копирования из глобальной памяти в разделяемую память, но я не вижу ничего о том, заботятся ли потоки в деформации (или целом SM) о совместимости в разделяемой памяти.

1 Ответ

1 голос
/ 07 января 2020

Чтобы получить хорошую производительность (избежать банковских конфликтов), достаточно лишь, чтобы каждый поток считывал / записывал с / на другой адрес разделяемой памяти, но каждый поток мог обращаться к этой памяти не последовательно без штрафа ?

конфликты банков возможны только между потоками в одной деформации, которые осуществляют доступ к общей памяти, и тогда возможны только для каждой инструкции (выданной). Инструкции, о которых я здесь говорю, являются инструкциями SASS (кода сборки GPU), но, тем не менее, должны быть непосредственно идентифицированы по ссылкам на совместно используемую память в исходном коде CUDA C ++.

Нет такой идеи, как конфликты банков:

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

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

Более того, это не достаточно, чтобы каждый поток считывал / записывал с / на свой адрес . Грубо говоря, для данной выданной инструкции (т. Е. Данного доступа) каждый поток в варпе должен читать из другого банка , иначе он должен читать с адреса, который совпадает с другим адресом в варпе. (широковещание).

Предположим, что мы имеем в виду 32-битные банки и схему из 32 банков. Совместно используемую память можно легко представить в виде 2D-схемы: 

Addr                Bank
 v     0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

 0     0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32    32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
64    64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
96    96 97 98 ...

Мы видим, что адреса / индекс / смещение / местоположения 0, 32, 64, 96 и c. находятся в одном банке. Адреса 1, 33, 65, 97 и др. c. находятся в одном банке и т. д. для каждого из 32 банков. Банки похожи на столбцы местоположений, когда адреса общей памяти визуализируются в этой двумерной схеме

Требование небанковского доступа к данной инструкции (загрузить или сохранить), выданной деформации, равно:

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

И повторять некоторые приведенные выше заявления несколько другим способом:

  • Если у меня есть все oop в коде CUDA нет возможности возникновения банковских конфликтов между отдельными итерациями этого l oop
  • Если у меня есть две отдельные строки кода CUDA C ++, то между банками не может возникнуть конфликт между банками. две отдельные строки кода CUDA C ++.
...