Поведение кеша в Compute Capability 7.5
Это мои предположения:
- Есть два типа загрузок: кэшированные и некэшированные. В первом трафик идет через L1 и L2, а во втором - только через L2.
- Поведение по умолчанию в Compute Capability 6.x и 7.x - это кэшированный доступ.
- Строка кэша L1 составляет 128 байтов, а строка кэша L2 - 32 байта, поэтому для каждой сгенерированной транзакции L1 должно быть четыре транзакции L2 (по одной на каждый сектор).
- В Nsight запрос SM->TEX означает команду уровня деформации, объединенную из 32 потоков. L2->TEX Returns и TEX->SM Returns - это мера того, сколько секторов передается между каждым блоком памяти.
Предполагая Compute Capability 7.5, вот мои вопросы:
- Третье предположение, похоже, подразумевает, что L2-> TEX Returns всегда должен быть кратным четырем для глобальных кэшированных загрузок, но это не всегда так. Что здесь происходит?
- Есть ли еще смысл маркировать указатели квалификаторами const и __restrict__? Раньше это было подсказкой компилятору, что данные доступны только для чтения и, следовательно, могут быть кэшированы в кэше L1/ текстуры, но теперь все данные кэшируются там, как только для чтения, так и не только для чтения.
- Исходя из моего четвертого предположения, я бы подумал, что всякий раз, когда TEX->SM Returns больше L2->TEX Returns, разница возникает из-за попаданий в кеш. Это потому, что при попадании в кеш вы получаете несколько секторов, считываемых из L1, но ни одного из L2. Это правда?
1 ответ
Решение
CC 6.x/7.x
- Размер строки кэша L1 составляет 128 байтов, разделенных на 4 32-байтовых сектора. В случае промаха из L2 будут извлечены только адресованные секторы.
- Размер строки кэша L2 составляет 128 байтов, разделенных на 4 32-байтовых сектора.
- CC 7.0 (HBM) 64B продвижение включено. Если пропущены нижние 64 байта строки кэша, нижние 64 байта будут извлечены из DRAM. Если пропущены верхние 64 байта строки кэша, будут извлечены верхние 64 байта.
- CC 6.x / 7.5 только 32-битные сектора будут извлечены из DRAM.
- С точки зрения политики кеширования L1
- В CC 6.0 по умолчанию включено кэширование нагрузки.
- В CC 6.x кэширование нагрузки по умолчанию отключено - см. Руководство по программированию.
- В CC 7.x кэширование нагрузки включено по умолчанию - см. PTX для получения подробной информации об управлении кешем
В Nsight Compute термин запросы варьируется от 6.x до 7.x.
- Для 5.x-6.x количество запросов на инструкцию варьировалось в зависимости от типа операции и ширины данных. Например, 32-разрядная нагрузка составляет 8 потоков / запрос, 64-разрядная нагрузка - 4 потока / запрос, а 128-разрядная нагрузка - 2 потока / запрос.
- Для 7.x запросы должны быть эквивалентны инструкциям, если в шаблоне доступа нет расхождения адресов, вызывающего сериализацию.
Ответы на ваши вопросы по CC 7.5
- Третье предположение, похоже, подразумевает, что L2->TEX Returns всегда должен быть кратным четырем для глобальных кэшированных загрузок, но это не всегда так. Что здесь происходит?
Модуль L1TEX будет извлекать только пропущенные 32B секторов в строке кэша.
- Есть ли еще смысл отмечать указатели квалификаторами const и restrict? Раньше это было подсказкой компилятору, что данные доступны только для чтения и, следовательно, могут быть кэшированы в кэше L1/ текстур, но теперь все данные кэшируются там, как только для чтения, так и не только для чтения.
Компилятор может выполнить дополнительную оптимизацию, если известно, что данные доступны только для чтения.
- Исходя из моего четвертого предположения, я мог бы подумать, что всякий раз, когда TEX->SM Returns больше L2->TEX Returns, разница возникает из-за попаданий в кеш. Это потому, что при попадании в кеш вы получаете несколько секторов, считываемых из L1, но ни одного из L2. Это правда?
L1TEX в SM возврат Ч / Б составляет 128 бит / цикл. От L2 к SM возвращается Ч / Б в секторах 32B.
Анализ рабочей нагрузки вычислительной памяти Nsight | Таблица L1/TEX Cache показывает
- Пропуски секторов в L2 (32B секторов)
- Возврат в SM (циклы == 1-128B)