CUDA: причины использования переменных предварительной обработки для определения размера проблемы

Question

Я кодирую CUDA в mex-файлах Matlab.Когда вы просматриваете примеры CUDA в Интернете или даже руководства от nvidia, вы часто видите использование переменных предварительной обработки для определения размера проблемы, например, длины вектора для сложения векторов или чего-то подобного.Я также написал свою программу так: Предварительная обработка переменных для определения размера проблемы.И я должен признать: мне это нравится, потому что вы можете получить доступ к ним везде в вашем коде, например, как ограничения в цикле или что-то в этом роде, без необходимости явно передавать их через аргумент функции.

НоЯ столкнулся со следующей проблемой: я хотел протестировать программу для нескольких разных размеров проблем, и поэтому мне нужно каждый раз снова компилировать код, передавая переменную предварительной обработки компилятору.Это не проблема, я уже закодировал тест, и он работает.Но теперь я просто удивляюсь, почему я выбрал эту версию, а не просто указал ее с помощью пользовательского ввода во время выполнения.И поэтому я ищу причины, по которым можно использовать переменные предварительной обработки вместо простой передачи размера задачи программе.

Спасибо!

Answer 1

Когда вы компилируете константы размера задачи в ядре, компилятор может выполнить некоторые классы оптимизации, которые он не может сделать, если размеры известны только во время выполнения. Развертывание полного цикла является очевидным примером.

В других случаях, например, размеры массивов разделяемой памяти, гораздо понятнее, если размеры компилируются; в противном случае вы должны передать общий размер разделяемой памяти во время запуска ядра и разбить эту память на необходимое вам количество разделяемых массивов. Это прекрасно работает, но код гораздо понятнее, если вы можете просто иметь статические объявления, для которых вам нужны размеры времени компиляции.

Answer 2

Основная причина заключается в том, что в общем случае размер проблемы будет тесно связан с архитектурой графического процессора, например, количество потоков на блок, количество блоков, объем разделяемой памяти на поток, количество регистров на поток и т. Д. В целомВсе эти цифры тщательно настроены для максимального использования доступных ресурсов, и вы не можете легко изменить размер проблемы динамически, сохраняя при этом оптимальную производительность.