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

Стандарт OpenCL определяет следующие параметры для получения информации об устройстве и скомпилированном ядре:

CL_DEVICE_MAX_COMPUTE_UNITS

CL_DEVICE_MAX_WORK_GROUP_SIZE

CL_KERNEL_WORK_GROUP_SIZE

CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE

Учитывая эти значения, как я могу рассчитать оптимальный размер рабочей группы и количество рабочих групп?

Ответы на вопрос(2)

Как сказал mfa, вы должны обнаружить это экспериментально. Я хотел бы добавить, что в зависимости от того, что вы вычисляете (в частности, размер заданий, то есть меньше или больше для каждого рабочего элемента), иногда удачной попыткой может быть:

Lots of work items with small work groups and each job item being small. Less work items with larger work groups and each job item being larger.

То есть, в основном, проверяют базовые случаи и выясняют, как это влияет на конвейер обработки.

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

Решение Вопроса

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

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

Несколько значений CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE будут оптимальными для вашего устройства. То, что это кратное число на самом деле, зависит от вашей схемы доступа к памяти и типа работы, которую вы выполняете с каждым рабочим элементом. Используйте 1 в качестве кратного, когда вы работаете с тяжелым ядром, связанным с вычислениями (ALU). Попробуйте большее кратное число, чтобы скрыть задержку памяти, если у вас узкий доступ к памяти. Используйте профилировщик, чтобы определить оптимальное время доступа и время ALU.

Оптимальное соотношение для ALU для выборки составляет 1: 1 для любого устройства. На практике это редко достигается, поэтому вы хотите поддерживать насыщенность банков ALU / SIMD. Это означает, что ALU: выборка должна быть больше 1, когда это возможно. Меньше 1 означает, что вы должны попробовать больший размер рабочей группы, чтобы лучше скрыть задержку памяти.

 Kentzo15 апр. 2012 г., 10:15
@ Гризли Я знаю, что CL_DEVICE_MAX_COMPUTE_UNITS, так как количество рабочих групп - плохая идея. Я использую это как множитель. Например. 10 * CL_DEVICE_MAX_COMPUTE_UNITS. Я по-прежнему заинтересован в методах, основанных на времени выполнения, для определения предпочтительного размера и количества рабочих групп, поскольку мне обычно приходится ставить в очередь десятки подзадач в рамках одной основной задачи.
 Kentzo11 апр. 2012 г., 07:08
Я нацеливаюсь на поддержку целого ряда устройств. Означает ли это, что я должен проверить свои ядра на каждом из них, чтобы получить оптимальные значения для постановки ядра в очередь?
 11 апр. 2012 г., 13:07
Протестируйте свой алгоритм на устройствах, к которым у вас есть доступ - результаты не должны сильно отличаться. Я предлагаю попробовать его на одном устройстве из каждой основной архитектуры, на которую вы хотите ориентироваться. Если вы можете, отрегулируйте параметры во время выполнения, чтобы попытаться оптимизировать. Это может настроить оптимальные значения, которые вы обнаружили во время разработки. Получение отзывов от конечного пользователя / клиента о фактических номерах аппаратных средств позволит вам сосредоточиться на усовершенствованиях для наиболее распространенных устройств.
 12 апр. 2012 г., 15:43
В общем используяCL_DEVICE_MAX_COMPUTE_UNITS не даст вам оптимальной производительности (если, возможно, вы не выполняете большую синхронизацию между рабочими группами, но это, как правило, плохая идея в любом случае). Обычно я спрашивал бы документацию о хороших ценностях, но я никогда не видел, чтобы больше рабочих групп снижало производительность, так что чем больше, тем труднее. Обратите внимание, что часть о выборе более высоких размеров рабочих групп для сокрытия задержки памяти (по крайней мере для gpus) верна, только если вы не используете достаточно рабочих групп (например, CL_DEVICE_MAX_COMPUTE_UNITS, поскольку CU обычно могут поддерживать более одной рабочей группы за раз).

Ваш ответ на вопрос