Выданы инструкции по загрузке/сохранению для воспроизведения

Есть две метрики nvprof относительно инструкций загрузки/сохранения: ldst_executed и ldst_issued. Мы знаем, что executed<=issued. Я ожидаю, что те загрузки/сохранения, которые выдаются, но не выполняются, связаны с предикациями ветвления и другими неверными предсказаниями. Однако из этого (слайд 9) документа и эта тема, инструкции, которые выдаются, но не выполняются, связаны с сериализацией и переиграть.

Я не знаю, относится ли эта причина к инструкциям по загрузке/сохранению или нет. Кроме того, я хотел бы знать, почему такая терминология используется для выпущенных, но не выполненных инструкций? Если по какой-либо причине происходит сериализация, инструкции выполняются несколько раз. Итак, почему они не учитываются как executed?

Любое объяснение этому?


person mahmood    schedule 14.08.2019    source источник


Ответы (2)


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

inst_executed — количество удаленных инструкций. inst_issued — количество выданных инструкций. Инструкция может быть выдана несколько раз в случае доступа к векторной памяти, конфликта адресов памяти, конфликта банков памяти и т. д. При каждой проблеме маска потока уменьшается до тех пор, пока все потоки не будут завершены.

Различие проводится по двум причинам: 1. Удаление инструкции указывает на завершение зависимости данных. Зависимость данных разрешается только 1 раз, несмотря на возможные повторы. 2. Соотношение между выданными и выполненными — это простой способ показать возможности экономии циклов выдачи деформирующего планировщика.

В Fermi и Kepler SM, если возникал конфликт памяти, инструкция воспроизводилась (повторно выдавалась) до тех пор, пока не завершались все потоки. Это было выполнено планировщиком деформации. Эти повторы потребляют циклы задач, уменьшая способность SM выдавать инструкции математическим каналам. В этом SM выданное > выполненное указывает на возможность оптимизации, особенно если выданное IPC высокое.

В Maxwell-Turing SM повторы для доступа к вектору, конфликты адресов и конфликты памяти воспроизводятся блоком памяти (общая память, L1 и т. д.) и не крадут циклы выпуска планировщика деформации. В этом SM выпускается очень редко более чем на несколько % выше выполненного.

ПРИМЕР: ядро ​​загружает 32-битное значение. Все 32 потока в варпе активны, и каждый поток обращается к уникальной строке кэша (шаг = 128 байт).

На Kepler (CC3.*) SM инструкция выдается 1 раз, а затем воспроизводится еще 31 раз, поскольку Kepler L1 может выполнять только 1 поиск тега на запрос.

inst_executed = 1 inst_issued = 32

На Kepler инструкцию приходится повторять заново для каждого запроса, пропущенного в L1. Если все потоки отсутствуют в кеше L1, то

inst_executed = 1 inst_issued >= 64 = 32 запроса + 32 повтора за промахи

В архитектуре Максвелла-Тьюринга воспроизведение выполняется системой памяти SM. Повторы могут ограничивать пропускную способность памяти, но не блокируют планировщик деформации от выдачи инструкций математическому конвейеру.

inst_executed = 1 inst_issued = 1

В Maxwell-Turing Nsight Compute/Perfworks выставляют счетчики пропускной способности для каждого из конвейеров памяти, включая количество циклов из-за конфликтов банков памяти, сериализации атомарных элементов, расхождения адресов и т. д.

person Greg Smith    schedule 15.08.2019
comment
Помимо конфликта банков, возможно ли повторное воспроизведение из-за ограниченного количества записей в MSHR для обслуживания промахов кеша на лету? Я имею в виду причины, отличные от конфликта памяти. - person mahmood; 15.08.2019
comment
В CC ‹ 5.0 существует множество причин, по которым инструкция воспроизводится повторно, включая, помимо прочего: векторную операцию с памятью (размер доступа > 32 бита), расхождение адресов, полный буфер записи, полную ожидающую таблицу промахов, сериализацию атомарных значений/сокращений до тот же адрес, запланировать повтор для чтения l1 miss после завершения, ... - person Greg Smith; 15.08.2019
comment
Спасибо. Похоже, что в nsight для CC›7 отсутствуют такие показатели (docs.nvidia.com/nsight-compute/NsightComputeCli/), где как выпущенные, так и выполненные ldst-инструкции не применимы. Должны ли мы ждать когда-нибудь будущих выпусков? Или есть что-то еще? - person mahmood; 16.08.2019

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

Как объяснено на слайде 9 презентации, которую вы связали, выполняемые инструкции — это инструкции, которые поток управления передает в вашей программе (в основном, количество строк ассемблерного кода, которые были запущены). Когда вы, например, выполняете глобальную инструкцию загрузки и запрос памяти не может быть обслужен немедленно (не попадает в кеш), GPU переключится на другой поток. Как только значение будет готово в кеше, а GPU переключится обратно на ваш поток, необходимо будет снова выполнить инструкцию загрузки, чтобы завершить выборку значения (см. также этот ответ и этой темы). Когда вы, например, получаете доступ к общей памяти и возникают конфликты банков, доступ к общей памяти должен быть воспроизведен несколько раз для разных потоков в варпе.

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

person Michael Kenzel    schedule 15.08.2019