Пять главных задач GPGPU: погружение в SYCL

[@e47ca0ef]

По поводу просадки производительности перемножения матриц при транспонировании матрицы B (В районе 29:00). Может ли быть это связано с таковым? Что при отсутствии транспонирования матрицы B происходит разреженный load её значений - и это дольше, чем load из транспонированной матрицы B - НО! этот разреженный load автоматически выгружает в кеш последующие элементы в строках матрицы B - и на следующих итерациях используются уже значения из кеша - т.е. в первой итерации происходит такой неявный prefetch данных для последующих итераций

[@e47ca0ef]

Хотя, похоже, выше я написал ерунду. И дело в том, как в каком порядке идёт объединение в условный "варп" потоков итерационного пространства. Если в один "варп" попадают потоки одной строки матрицы C (т.е. потоки, рассчитывающие C[0,0], C[0,1], ..., C[0, 31]), то чтение из матрицы B становится когерентным, а из транспонированной матрицы B операция чтения памяти "варпом" уже некогерентна. Предполагаю, что, если поменять местами размерности итерационного пространства, то временя работы с исходной и с транспонированный матрицей B также поменяются

[@victormustya1745]

В районе 29:00, транспонирование. Допустим, у тебя dispatch по 16. Тогда до транспонирования у тебя один hw thread грузил 16 идущих подряд в памяти значений, и железо могло этот gather оптимизировать, там было всё хорошо с локальностью данных. А после транспонирования у тебя gather становится сильно разреженным. Попробуй наоборот, транспонировать матрицу A

[@tilir]

Как раз наоборот, после транспонирования грузятся рядом идущие значения:
// iterate the same K dimension
for (int K = 0; K < AY; K++)
Sum += A[Row * AY + K] * B[Col * AY + K];
см. github.com/tilir/ocl/blob/master/sycl/sgemm/matmult_transposed.cc

[@victormustya1745]

@@tilir ты смотришь с точки зрения одного виртуального потока. Посмотри в целом на инструкцию gather. Она в SIMT модели работает для 16 потоков. В случае нетранспонированной матрицы она грузит на каждой итерации 16 элементов из соседних столбцов. То есть 16 чисел подряд. Когда матрица транспонирована, за итерацию грузится столбец из 16 строк. То есть 16 чисел с достаточно большим stride. В случае нетранспонированной матрицы можно вообще сделать subgroup block load. А если матрицу транспонировать, то уже нельзя

[@tilir]

Что с транспонированием что без, там абсолютно одинаковый visaasm. Сейчас скачал последний релиз IGC собрал из SPIRV под Linux. Выглядит это вот так:
// матрица A
svm_gather.4.1 (M1, 16) V0167.0 V0173.0
svm_gather.4.1 (M5, 16) V0168.0 V0174.0
// матрица B
svm_gather.4.1 (M1, 16) V0201.0 V0207.0
svm_gather.4.1 (M5, 16) V0202.0 V0208.0
// Умножили
mad (M1, 16) V0094(0,0) V0207(0,0) V0173(0,0) V0094(0,0)
mad (M5, 16) V0095(0,0) V0208(0,0) V0174(0,0) V0095(0,0)
Причём в обоих случаях, никто там блочные лоады не собирает.
Увы, профилировщик у меня на TGLLP на моём ноуте не завёлся и посмотреть причины почему мы всё-таки так плохи не получилось. Я тоже подозреваю что после транспонирования gather тянется дальше. Но опять-таки рядом с ним нигде не написано что для него дальше == хуже. И так как это TGLLP, никаких кешей там не завезли.
В общем если выяснишь что-то конкретное пиши в комменты, будет очень интересно =)

[@victormustya1745]

@@tilir gather одинаковый. В рантайме адреса у этого gather разные. IGC, понятное дело, не собирает никаких блочных лоадов. Но железу проще загрузить 16 интов из памяти подряд, чем со страйдом --- они все в одном кэшлайне. А меньше кэшлайна железо всё равно не грузит. В случае транспонированой матрицы gather соберёт 16 разных кэшлайнов.

[@victormustya1745]

@@tilir несмотря на то, что это tgllp, кэш там есть, как раз те самые 64k/subslice. Иначе откуда бы взялась slm