В графических процессорах Fermi и Kepler, когда выполнялась глобальная транзакция, она всегда имела размер 128 байт, а размер строки кэша L1 (если включен) составлял 128 байт.С Максвеллом и Паскалем эти характеристики изменились.В частности, чтение части кеш-линии L1 не обязательно запускает полную транзакцию шириной 128 байт.Это довольно легко обнаружить / доказать с помощью микробенчмаркинга.
По сути, размер глобальной транзакции загрузки изменился с учетом определенной степени гранулярности.Исходя из этого изменения размера транзакции, возможно, что потребуется несколько транзакций, где ранее требовалась только 1.Насколько я знаю, ничего из этого явно не опубликовано или подробно, и я не смогу сделать это здесь.Однако я думаю, что мы можем ответить на ряд ваших вопросов, не давая точного описания того, как рассчитываются глобальные транзакции загрузки.
gld_transactions = 536870914, что означает, что каждая глобальная транзакция загрузки должна быть в среднем4 ГБ / 536870914 = 8 байтов.Это согласуется с gld_transactions_per_request = 16.000000: каждая деформация считывает 128 байтов (1 запрос), и если каждая транзакция составляет 8 байтов, то нам нужно 128/8 = 16 транзакций на запрос.Почему это значение так низко?Я ожидал бы идеального слияния, поэтому что-то вроде 4 (или даже 1) транзакций / запроса.
Это склад ума (1 транзакция на запрос для полностью объединенных нагрузок 32-битного количества на поток) было бы правильно на таймфрейме Ферми / Кеплера.Это больше не подходит для графических процессоров Maxwell и Pascal.Как вы уже подсчитали, размер транзакции меньше 128 байт, и поэтому количество транзакций на запрос больше 1. Но это не указывает на проблему эффективности как таковую (как это было бы в Fermi /Кеплер сроки).Итак, давайте просто признаем, что размер транзакции может быть меньше, и поэтому транзакции на запрос могут быть выше, даже если базовый трафик по существу эффективен на 100%.
gst_transactions = 134217728 и gst_transactions_per_request = 4.000000, поэтому хранениепамять эффективнее?
Нет, это не то, что это значит.Это просто означает, что кванты подразделения могут быть разными для нагрузок (транзакции загрузки) и хранилищ (транзакции хранилища).Это 32-байтовые транзакции.В любом случае, загружает или хранит, транзакции являются и должны быть полностью эффективными в этом случае.Запрашиваемый трафик соответствует фактическому трафику, и другие метрики профилировщика подтверждают это.Если фактический трафик был намного выше, чем запрошенный трафик, это было бы хорошим показателем неэффективных нагрузок или хранилищ:
1 gld_requested_throughput Requested Global Load Throughput 150.32GB/s 150.32GB/s 150.32GB/s
1 gst_requested_throughput Requested Global Store Throughput 150.32GB/s 150.32GB/s 150.32GB/s
1 gld_throughput Global Load Throughput 150.32GB/s 150.32GB/s 150.32GB/s
1 gst_throughput Global Store Throughput 150.32GB/s 150.32GB/s 150.32GB/s
Запрошенная и достигнутая глобальная пропускная способность загрузки / хранения (gld_requested_throughput, gst_requested_throughput, gld_throughput, gst_throughput) составляет 150,32 ГБ / с каждый.Я ожидал бы более низкую пропускную способность для нагрузок, чем для магазинов, так как у нас больше транзакций на запрос.
Опять же, вам придется скорректировать свой способ мышления, чтобы учитывать переменные размеры транзакций.Пропускная способность определяется потребностями и эффективностью, связанными с выполнением этих потребностей.И загрузки, и хранилища полностью эффективны для вашего дизайна кода, поэтому нет оснований думать, что существует или должен существовать дисбаланс в эффективности.
gld_transactions = 536870914, но l2_read_transactions = 134218800. Глобальная память всегдадоступ через кэш L1 / L2.Почему количество транзакций чтения L2 намного меньше?Это не может быть все кэшировано в L1.(global_hit_rate = 0%)
Это просто из-за разного размера транзакций. Вы уже подсчитали, что кажущийся размер транзакции глобальной загрузки составляет 8 байт, и я уже указывал, что размер транзакции L2 составляет 32 байта, поэтому имеет смысл соотношение 4: 1 между общим количеством транзакций. , поскольку они отражают одно и то же движение одних и тех же данных при просмотре через 2 разных объектива. Обратите внимание, что всегда было несоответствие между размером глобальных транзакций и размером транзакций L2 или транзакций в DRAM. Просто их соотношение может варьироваться в зависимости от архитектуры графического процессора и, возможно, других факторов, таких как схемы загрузки.
Некоторые заметки:
Я не смогу ответить на такие вопросы, как «почему это так?» Или «почему Паскаль изменился с Ферми / Кеплера?» или «учитывая этот конкретный код, что бы вы прогнозировали как необходимые глобальные транзакции загрузки на этом конкретном графическом процессоре?», или «как правило, для этого конкретного графического процессора, как бы я рассчитывал или прогнозировал размер транзакции?»
Кроме того, NVIDIA предлагает новые инструменты профилирования (Nsight Compute и Nsight Systems) для работы с графическими процессорами. Многие из показателей эффективности и транзакций по запросу, которые доступны в nvprof , пропали в новой цепочке инструментов. Таким образом, эти установки в любом случае должны быть нарушены, потому что эти методы определения эффективности не будут доступны в будущем, основываясь на текущем наборе метрик.
Обратите внимание, что использование параметров компиляции, таких как -Xptxas -dlcm=ca, может повлиять на (L1) поведение кэширования. Однако я не ожидаю, что кэши окажут значительное влияние на производительность или эффективность для этого конкретного кода копии.
Это возможное уменьшение размера транзакции, как правило, хорошо. Это не приводит к потере эффективности для шаблонов трафика, таких как представленные в этом коде, а для некоторых других кодов позволяет (менее 128-байтных) запросов удовлетворяться при меньшей потере пропускной способности.
Хотя это не совсем Паскаль, здесь - это более точный пример возможной изменчивости этих измерений для Максвелла. Паскаль будет иметь аналогичную изменчивость. Кроме того, небольшая подсказка об этом изменении (особенно для Паскаля) была дана в Руководстве по настройке Паскаля . Он ни в коем случае не предлагает полного описания и не объясняет все ваши наблюдения, но намекает на общую идею о том, что глобальные транзакции больше не фиксируются на 128-байтовом размере.