Предотвращение расхождения потоков CUDA для операций типа MISD

Как часть более крупного кода, у меня есть решатель CUDA RK4, который параллельно интегрирует большое количество ODE (может быть 1000+). Одним из шагов этой операции является вычисление «xdot», которое отличается для каждого уравнения (или элемента данных). На данный момент у меня есть настройка ветвления с переключением для вычисления значения для каждого элемента данных в ядре. Все разные потоки используют одни и те же 3-6 элементов данных для вычисления своих выходных данных, но по-разному. Например, для потока 1 это может быть

xdot = данные[0]*данные[0] + данные[1];

в то время как для потока 2 это может быть,

xdot = -2*данные[0] + данные[2];

и так далее. Итак, если у меня есть сто элементов данных, путь выполнения для каждого из них разный.

Есть ли способ избежать/уменьшить штраф за расхождение потоков в таком сценарии? Поможет ли запуск только одного потока на блок?


c cuda thrust
person Thomas Antony    schedule 19.07.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Запуск одного потока на блок просто обнуляет 31/32 потока в одном запущенном вами варпе и тратит впустую много циклов и возможностей скрыть задержку. Я бы никогда не рекомендовал это, независимо от того, сколько штрафов за расхождение ветвей понес ваш код.

Ваше приложение звучит довольно ортогонально базовой парадигме программирования CUDA, и на самом деле вы мало что можете сделать, чтобы избежать штрафов за расхождение ветвей. Один из подходов, который мог бы немного улучшить ситуацию, состоял бы в том, чтобы выполнить некоторый предварительный анализ выражений для каждого уравнения и сгруппировать вместе те, которые имеют общие арифметические термины. Современное оборудование может запускать несколько ядер одновременно, поэтому может быть выгоднее сгруппировать вычисления, использующие одинаковые термины, в разные ядра и запускать их одновременно, а не одно большое ядро. CUDA поддерживает шаблоны C++, и это может быть хорошим способом генерировать много кода ядра из относительно узкой базы и сделать большую часть логики статически оцениваемой, что может помочь компилятору. Но не ждите чудес - ваша проблема, вероятно, лучше подходит для другой архитектуры, чем для графического процессора (например, Intel Xeon Phi).

person talonmies    schedule 20.07.2013
comment
Спасибо! Я посмотрю на это. Что касается использования других архитектур, то это только часть проблемы. Остальное по своей природе очень параллельно и довольно хорошо масштабируется с использованием CUDA. Я пытался посмотреть, есть ли шанс оптимизации в этой конкретной части. - person Thomas Antony; 24.08.2013