Який код краще для оптимізації прогнозування галузей?

Враховуючи галузеве передбачення, а також ефект оптимізацій компілятора, який код має тенденцію до вищої ефективності?

Зауважте, що bRareExceptionPresent є нечастою умовою. Це не нормальний шлях логіки.

/* MOST COMMON path must branch around IF clause */

bool SomeFunction(bool bRareExceptionPresent)
{
  // abort before function
  if(bRareExceptionPresent)
  {
     return false;
  }    
  .. function primary body ..    
  return true;
}

/* MOST COMMON path does NOT branch */

bool SomeFunction(bool bRareExceptionPresent)
{
  if(!bRareExceptionPresent)
  {
    .. function primary body ..
  }
  else
  {
    return false;
  }
  return true;
}

У сучасному світі це не має великого значення, якщо воно взагалі є.

Динамічне прогнозування гілок (про що думали десятиліттями (див . Аналіз навантажень системи динамічного прогнозування гілок), опублікований у 1996 році) є досить поширеним місцем.

Приклад цього можна знайти в процесорі ARM. З інформаційного центру Arm з прогнозування філії

Для підвищення точності прогнозування галузей використовується комбінація статичних та динамічних методик.

Тоді питання: "що таке динамічне прогнозування гілок в кронштейні?" Тривале читання прогнозування динамічної гілки показує, що вона використовує 2-бітну схему прогнозування (описану в статті), будує інформацію про те, чи гілка сильно або слабко взята чи не взята.

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

Для статичного прогнозування він дивиться на те, як виглядає сам код і яким чином зроблено гілку на тесті - на попередню інструкцію або одну далі в коді:

Схема, що використовується в процесорі ARM1136JF-S, передбачає, що всі передові умовні гілки не взяті і всі відсталі гілки прийняті. Близько 65% усіх гілок передує достатньому циклу нерозгалуження, який можна повністю передбачити.

Як згадував Спаркі, це ґрунтується на розумінні, що циклі частіше, ніж ні, циклічно. Петля відгалужується назад (вона має гілку в кінці циклу, щоб перезапустити її вгорі) - зазвичай це робить.

Небезпека спробувати вгадати компілятор полягає в тому, що ви не знаєте, як цей код насправді збирається (і оптимізується). І здебільшого це не має значення. При динамічному прогнозуванні двічі через функцію він передбачить пропуск через оператор захисту для передчасного повернення. Якщо продуктивність двох промитих трубопроводів має вирішальне значення, варто потурбуватися про інші.

Час, необхідний для читання одного стилю над іншим, швидше за все, має велике значення - зробити код чистим, щоб людина міг його читати, оскільки компілятор буде робити чудово, незалежно від того, наскільки брудно чи ідеалізовано ви пишете код.

Я розумію, що перший раз, коли CPU стикається з відділенням, він передбачить (якщо він підтримується), що передні гілки не приймаються, а назад - гілки. Обґрунтуванням цього є те, що петлі (як правило, гілки назад) приймаються.

На деяких процесорах ви можете дати підказку в інструкції по збірці, який шлях є більш імовірним. Деталі цього втечі мені зараз.

Крім того, деякі компілятори C також підтримують статичне передбачення гілок, щоб ви могли сказати компілятору, яка гілка є більшою ймовірністю. У свою чергу він може реорганізувати створений код або скористатися модифікованими інструкціями, щоб скористатися цією інформацією (або навіть просто вилучити її з уваги).

__builtin_expect((long)!!(x), 1L)  /* GNU C to indicate that <x> will likely be TRUE */
__builtin_expect((long)!!(x), 0L)  /* GNU C to indicate that <x> will likely be FALSE */

Сподіваюсь, це допомагає.