Чому порівняння настільки дорогі на GPU?

Намагаючись покращити продуктивність мого класу виявлення зіткнень, я виявив, що ~ 80% часу, витраченого на gpu, він витратив на умови if / else, просто намагаючись з'ясувати межі для відра, через який він повинен пройти цикл.

Точніше:

1. кожен потік отримує ідентифікатор, за допомогою цього ідентифікатора він отримує свій трикутник із пам'яті (по 3 цілих числа кожен), а за допомогою цих 3 він отримує вершини (3 поплавця в кожній).

2. Потім він перетворює вершини в цілі точки сітки (в даний час 8x8x8) і перетворює їх у трикутні межі на цій сітці

3. Щоб перетворити 3 точки в межі, він знаходить min / max кожного виміру серед кожної з точок

Оскільки в мові програмування, яку я використовую, відсутня властива minmax, я зробив її сам, виглядає так:

procedure MinMax(a, b, c):
   local min, max

   if a > b:
      max = a
      min = b
   else:
      max = b
      min = a
   if c > max:
      max = c
   else:
      if c < min:
         min = c

   return (min, max)

Таким чином, в середньому це повинно бути 2,5 * 3 * 3 = 22,5 порівняння, що закінчується їжею набагато більше часу, ніж фактичні тести на перетину трикутника - краю (приблизно 100 * 11-50 інструкцій).

Насправді я виявив, що попередній обчислення необхідних відро на процесорі (однопотокова, без векторизації), складання їх у подання gpu разом із визначенням відра і надання gpu робити ~ 4 додаткових читання на один потік було в 6 разів швидше, ніж спроба щоб вияснити межі на місці. (зауважте, що вони перераховуються перед кожним виконанням, оскільки я маю справу з динамічними сітками)

То чому порівняння настільки жахливо повільне на gpu?

GPU - це архітектура SIMD. У архітектурах SIMD кожна інструкція повинна бути виконана для кожного елемента, який ви обробляєте. (З цього правила є виняток, але це рідко допомагає).

Отже, у вашому MinMaxрозпорядженні не тільки кожен виклик повинен отримати всі три інструкції гілки (навіть якщо в середньому оцінюється лише 2,5), але і кожен оператор призначення також займає цикл (навіть якщо він насправді не "виконується" ).

Ця проблема іноді називається розбіжністю ниток . Якщо ваша машина має щось на кшталт 32 смуг виконання SIMD, вона все одно матиме лише один блок отримання. (Тут термін "потік" в основному означає "смуга виконання SIMD".) Отже, внутрішньо у кожній смузі виконання SIMD є біт "Я ввімкнено / вимкнено", і гілки насправді просто маніпулюють цим бітом. (Виняток полягає в тому, що в точці, коли кожна смужка SIMD стає відключеною, блок вибору, як правило, переходить безпосередньо до пункту "else".)

Отже, у вашому коді виконується кожна смужка виконання SIMD:

compare (a > b)
assign (max = a if a>b)
assign (min = b if a>b)
assign (max = b if not(a>b))
assign (min = a if not(a>b))
compare (c > max)
assign (max = c if c>max)
compare (c < min if not(c>max))
assign (min = c if not(c>max) and c<min)

Може статися так, що на деяких графічних процесорах ця конверсія умовних умов у прогнозування відбувається повільніше, якщо GPU робить це сам. Як вказував @ PaulA.Clayton, якщо у вашій мові програмування та архітектурі передбачена умовна операція переміщення (особливо одна із форм if (c) x = y else x = z), ви могли б зробити краще. (Але, напевно, не набагато краще).

Крім того, розміщення c < minумовного всередині одиниці elseне c > maxє зайвим. Це, безумовно, нічого не економить, і (враховуючи, що GPU повинен автоматично перетворити його на передбачення), насправді може шкодити, щоб він вклався у двох різних умовах.