Предположим, что у нас есть 2 ^ 10 ядер CUDA и 2 ^ 20 точек данных. Мне нужно ядро, которое обработает эти точки и предоставит истину / ложь для каждой из них. Так что у меня будет 2 ^ 20 бит. Пример:
bool f(x) { return x % 2? true : false; }
void kernel(int* input, byte* output)
{
tidx = thread.x ...
output[tidx] = f(input[tidx]);
...or...
sharedarr[tidx] = f(input[tidx]);
sync()
output[blockidx] = reduce(sharedarr);
...or...
atomic_result |= f(input[tidx]) << tidx;
sync(..)
output[blckidx] = atomic_result;
}
Thrust / CUDA имеет несколько алгоритмов, таких как «разбиение», «преобразование», которые предоставляют аналогичные альтернативы.
У меня вопрос, когда я пишу соответствующее ядро CUDA с предикатом, который предоставляет соответствующий результат bool,
я должен использовать один байт для каждого результата и напрямую сохранить результат в выходном массиве? Выполнение одного шага для расчета и выполнение следующего шага для сокращения / разбиения позже.
я должен сжать вывод в разделяемой памяти, используя один байт для 8 потоков, а затем в конце записать результат из разделяемой памяти в выходной массив?
я должен использовать атомарные переменные?
Какой лучший способ написать такое ядро и наиболее логичную структуру данных, чтобы сохранить результаты? Лучше использовать больше памяти и просто делать больше операций записи в основную память вместо того, чтобы пытаться сжимать результат перед записью в область памяти результата?
Нет никакого компромисса между скоростью и размером данных при использовании __ballot()
варп-голосование присуще эффективно упаковать результаты.
Предполагая, что вы можете переопределить output
чтобы иметь тип uint32_t и размер вашего блока кратен размеру основы (32), вы можете просто сохранить упакованный вывод, используя
output[tidx / warpSize] = __ballot(f(input[tidx]));
Обратите внимание, что это заставляет все потоки деформации пытаться сохранить результат __ballot()
, Только одна нить варпа будет успешной, но, поскольку все их результаты идентичны, не имеет значения, какая из них будет.
Других решений пока нет …