Блог

Какой правильный вариант для измерения пропускной способности с помощью nvprof —metrics из командной строки? Я использую flop_dp_efficiency для получения процента пиковых флопов, но, похоже, в руководстве есть много вариантов измерения полосы пропускания, которые я не совсем понимаю, что я измеряю. например, dram_read, dram_write, gld_read, gld_write все выглядят одинаково для меня. Кроме того, должен ли я сообщать bandwdith как сумму пропускной способности чтения и записи, предполагая, что оба происходят одновременно?

Редактировать:

Основываясь на отличном ответе с диаграммой, какова будет пропускная способность, идущая от памяти устройства к ядру? Я думаю использовать минимальную пропускную способность (чтение запись) на пути от ядра к памяти устройства, которая, вероятно, является dram для кэша L2.

Я пытаюсь определить, ограничено ли ядро вычислениями или памятью, измеряя ФЛОПЫ и пропускную способность.

Чтобы понять метрики профилировщика в этой области, необходимо иметь представление о модели памяти в графическом процессоре. Я нахожу диаграмму, опубликованную в документации Nsight Visual Studio edition, полезной. Я пометил диаграмму пронумерованными стрелками, которые относятся к пронумерованным метрикам (и направлению передачи) Я перечислил ниже:

Пожалуйста, обратитесь к справочнику CUDA profiler metrics для описания каждой метрики:

1. dram_read_throughput, dram_read_transactions
2. dram_write_throughput, dram_write_transactions
3. sysmem_read_throughput, sysmem_read_transactions
4. sysmem_write_throughput, sysmem_write_transactions
5. l2_l1_read_transactions, l2_l1_read_throughput
6. l2_l1_write_transactions, l2_l1_write_throughput
7. l2_tex_read_transactions, l2_texture_read_throughput
8. текстура доступна только для чтения, на этом пути транзакции невозможны
9. shared_load_throughput, shared_load_transactions
10. shared_store_throughput, shared_store_transactions
11. l1_cache_local_hit_rate
12. l1 — это кэш для сквозной записи, поэтому для этого пути нет (независимых) метрик — обратитесь к другим локальным метрикам
13. l1_cache_global_hit_rate
14. см. Примечание к 12
15. gld_efficiency, gld_throughput, gld_transactions
16. gst_efficiency, gst_throughput, gst_transactions

Примечания:

1. Стрелка справа налево указывает на активность чтения. Стрелка слева направо указывает на активность записи.
2. «глобальный» — это логическое пространство. Это относится к логическому адресному пространству с точки зрения программистов. Транзакции, направленные в «глобальное» пространство, могут оказаться в одном из кэшей, в sysmem или в памяти устройства (dram). «dram», с другой стороны, является физическим объектом (как, например, кэши L1 и L2). Все «логические пробелы» показаны в первом столбце диаграммы сразу справа от столбца «ядро». Остальные столбцы справа — это физические объекты или ресурсы.
3. Я не пытался пометить каждую возможную метрику памяти местоположением на диаграмме. Надеюсь, эта диаграмма будет поучительной, если вам нужно выяснить другие.

С учетом приведенного выше описания, возможно, на ваш вопрос все еще не может быть ответа. Затем вам необходимо будет уточнить свой запрос: «что вы хотите точно измерить?» Однако, исходя из вашего вопроса, как написано, вы, вероятно, захотите взглянуть на показатели dram_xxx, если вас интересует фактическая потребляемая пропускная способность памяти.

Кроме того, если вы просто пытаетесь получить оценку максимально доступной пропускной способности памяти, использование примера кода CUDA bandwidthTest , вероятно, является самым простым способом получить прокси-измерение для этого. Просто используйте сообщенный номер пропускной способности устройства для устройства в качестве оценки максимальной пропускной способности памяти, доступной для вашего кода.

Объединяя вышеупомянутые идеи, метрика dram_utilization дает масштабированный результат, который представляет часть (от 0 до 10) общей доступной пропускной способности памяти, которая фактически использовалась.