CUDA - операции над отдельными элементами матрицы - получение идей

Question

Я собираюсь написать ядро ​​CUDA для выполнения одной операции над каждым отдельным элементом матрицы (например, квадратное укоренение каждого элемента, возведение в степень или вычисление синуса / косинуса, если все числа находятся между [-1; 1] и т.д ..)

Я выбрал размеры сетки блоков / потоков, и я думаю, что код довольно прост и прост, но я спрашиваю себя ... что я могу сделать, чтобы максимизировать объединение / заполнение SM?

Моя первая идея состояла в том, чтобы заставить все полусвернутые (16 потоков) загружать ансамбль данных из глобальной памяти и затем помещать их все для вычислений, но он обнаруживает, что не хватает параллелизации передачи / вычисления памяти .. Я имею в виду все потоки загрузить данные, затем вычислить, затем загрузить снова данные, затем снова вычислить .. это звучит очень плохо с точки зрения производительности.

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

Я не совсем уверен, что дал правильное представление о моей проблеме, я просто получаю идеи, прежде чем приступить к работе над чем-то конкретным.

Каждый комментарий / предложение / критик хорошо принят и спасибо.

Answer 1

Если вы определили сетку таким образом, чтобы потоки считывали основное измерение массива, содержащего вашу матрицу, то вы уже гарантировали объединенный доступ к памяти, и для повышения производительности ничего не нужно делать. Подобные операции со сложностью O (N) действительно не содержат достаточной арифметической интенсивности, чтобы обеспечить хорошую параллельную скорость по сравнению с оптимизированной реализацией процессора. Часто лучшей стратегией является объединение нескольких операций O (N) в одно ядро ​​для улучшения соотношения транзакций FLOP и памяти.

Answer 2

На мой взгляд, ваша проблема заключается в следующем:

load data ensemble from global memory

Кажется, что ваша идея алгоритма такова:

1. Сделайте что-нибудь на процессоре - есть матрица
2. Перенос матрицы из глобальной памяти в устройство
3. Выполнение операции над каждым элементом
4. Перенос матрицы с устройства в глобальную память
5. Сделайте что-нибудь еще на процессоре - иногда возвращайтесь назад 1.

Этот вид вычислений почти всегда ограничен пропускной способностью ввода / вывода (IO = IO памяти), а не ограничен вычислительной мощностью.Вычисления GPGPU могут поддерживать очень высокую пропускную способность памяти - но только из памяти устройства в gpu - передача из глобальной памяти всегда происходит по очень медленному PCIe (медленнее по сравнению с соединением памяти устройства, которое может обеспечить до 160 ГБ / с + набыстрые карты).Поэтому одним из главных моментов для получения хороших результатов является сохранение данных (матрицы) в памяти устройства - желательно генерировать их даже там, где это возможно (зависит от вашей проблемы).Никогда не пытайтесь переносить данные между процессором и процессором и обратно, так как накладные расходы на передачу съедают все ваше ускорение.Также имейте в виду, что ваша матрица должна иметь определенный размер для амортизации накладных расходов на перенос, которых вы не можете избежать (вычисление матрицы с 10 x 10 элементами не принесло бы почти ничего, черт возьми, это даже стоило бы дороже)

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

Answer 3

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

Я видел много проектов, демонстрирующих «большие» преимущества GPU по сравнению с CPU.Они редко выдерживают проверку.Конечно, глупые менеджеры, которые хотят произвести впечатление на своих менеджеров, хотят показать, насколько "передовой край" его группы.

Кто-то в отделе месяцами тратит время на оптимизацию глупого кода GPU (который, как правило, в 8 раз труднее читать, чем эквивалентный код процессора), а затем «эквивалентный» код процессора, написанный какой-то индийской компанией пота (программист,последний проект был PGP), скомпилируйте его с самой медленной версией gcc, которую они могут найти, без оптимизации, затем рекламируйте их 2-кратное улучшение скорости.И, кстати, многие упускают из виду скорость ввода-вывода как-то не важно.