Есть ли подсказка компилятора для GCC, чтобы заставить предсказание ветвления всегда идти определенным путем?

Для архитектур Intel есть ли способ инструктировать компилятор GCC генерировать код, который всегда вызывает предсказание ветвления определенным образом в моем коде? Поддерживает ли это оборудование Intel? А как насчет других компиляторов или оборудования?

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

for (;;) {
  if (normal) { // How to tell compiler to always branch predict true value?
    doSomethingNormal();
  } else {
    exceptionalCase();
  }
}

В качестве следующего вопроса для Евджана Мустафы, может ли подсказка просто указать подсказку, когда процессор впервые встречает инструкцию, все последующие предсказания ветвления работают нормально?

Начиная с C ++ 20 вероятные и маловероятные атрибуты должны быть стандартизированы и уже поддерживаются в g ++ 9 . Итак, как обсуждалось здесь , вы можете написать

if (a>b) {
  /* code you expect to run often */
  [[likely]] /* last statement */
}

например, в следующем коде блок else становится встроенным благодаря [[unlikely]]блоку if

int oftendone( int a, int b );
int rarelydone( int a, int b );
int finaltrafo( int );

int divides( int number, int prime ) {
  int almostreturnvalue;
  if ( ( number % prime ) == 0 ) {
    auto k                         = rarelydone( number, prime );
    auto l                         = rarelydone( number, k );
    [[unlikely]] almostreturnvalue = rarelydone( k, l );
  } else {
    auto a            = oftendone( number, prime );
    almostreturnvalue = oftendone( a, a );
  }
  return finaltrafo( almostreturnvalue );
}

ссылка Godbolt для сравнения наличия / отсутствия атрибута

GCC поддерживает функцию, __builtin_expect(long exp, long c)обеспечивающую такую ​​возможность. Вы можете проверить документацию здесь .

Где expиспользуется условие, а где c- ожидаемое значение. Например, в вашем случае вы хотите

if (__builtin_expect(normal, 1))

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

#define likely(x)    __builtin_expect (!!(x), 1)
#define unlikely(x)  __builtin_expect (!!(x), 0)

просто чтобы облегчить задачу.

Имейте в виду, что:

1. это нестандартно
2. предсказатель ветвления компилятора / процессора, вероятно, более квалифицирован, чем вы, в принятии таких решений, поэтому это может быть преждевременной микрооптимизацией

gcc имеет long __builtin_expect (long exp, long c) ( выделено мной ):

Вы можете использовать __builtin_expect, чтобы предоставить компилятору информацию о предсказании ветвления. В общем, вы должны предпочесть использовать для этого фактическую обратную связь с профилем (-fprofile-arcs), так как программисты, как известно, плохо предсказывают, как их программы на самом деле работают . Однако есть приложения, в которых сложно собрать эти данные.

Возвращаемое значение - это значение exp, которое должно быть интегральным выражением. Семантика встроенного такова, что ожидается, что exp == c. Например:

if (__builtin_expect (x, 0))
   foo ();

указывает, что мы не ожидаем вызова foo, поскольку ожидаем, что x будет равно нулю. Поскольку вы ограничены интегральными выражениями для exp, вам следует использовать такие конструкции, как

if (__builtin_expect (ptr != NULL, 1))
   foo (*ptr);

при тестировании указателей или значений с плавающей запятой.

Как отмечается в документации, вы должны предпочесть использовать фактическую обратную связь с профилем, и в этой статье показан практический пример этого и то, как в их случае, по крайней мере, в конечном итоге становится лучше, чем использование __builtin_expect. Также см. Как использовать оптимизацию под руководством профиля в g ++? ,

Мы также можем найти статью для новичков в ядре Linux о макросах ядра вероятно () и маловероятно (), которые используют эту функцию:

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

Обратите внимание на то, что !!используется в макросе, мы можем найти объяснение этого в разделе Почему использовать !! (условие) вместо (условие)? ,

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

Обратите внимание: хотя встроенные команды не переносятся, clang также поддерживает __builtin_expect .

Также на некоторых архитектурах это может не иметь значения .

Нет, нет. (По крайней мере, на современных процессорах x86.)

__builtin_expectупомянутые в других ответах влияют на то, как gcc упорядочивает код сборки. Он не влияет напрямую на предсказатель ветвления ЦП. Конечно, переупорядочение кода окажет косвенное влияние на предсказание ветвлений. Но на современных процессорах x86 нет инструкции, которая говорит ЦП «предположить, что эта ветвь занята / не занята».

См. Этот вопрос для более подробной информации: Intel x86 0x2E / 0x3E Prefix Branch Prediction действительно используется?

Чтобы быть ясным, __builtin_expectи / или использование -fprofile-arcs может улучшить производительность вашего кода, как путем предоставления подсказок для предсказателя ветвления через макет кода (см. Оптимизация производительности сборки x86-64 - Выравнивание и прогнозирование ветвления ), так и за счет улучшения поведения кеша за счет отделения «маловероятного» кода от «вероятного».

Правильный способ определения вероятных / маловероятных макросов в C ++ 11 следующий:

#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)

Этот метод, в отличие от него [[likely]], совместим со всеми версиями C ++, но полагается на нестандартное расширение __builtin_expect.

Когда эти макросы определены таким образом:

#define LIKELY(condition) __builtin_expect(!!(condition), 1)

Это может изменить смысл ifоператоров и нарушить код. Рассмотрим следующий код:

#include <iostream>

struct A
{
    explicit operator bool() const { return true; }
    operator int() const { return 0; }
};

#define LIKELY(condition) __builtin_expect((condition), 1)

int main() {
    A a;
    if(a)
        std::cout << "if(a) is true\n";
    if(LIKELY(a))
        std::cout << "if(LIKELY(a)) is true\n";
    else
        std::cout << "if(LIKELY(a)) is false\n";
}

И его вывод:

if(a) is true
if(LIKELY(a)) is false

Как видите, определение LIKELY using !!в качестве приведения boolнарушает семантику if.

Дело здесь не в этом operator int()и operator bool()должно быть связано. Это хорошая практика.

Вместо этого использование !!(x)вместо static_cast<bool>(x)теряет контекст для контекстных преобразований C ++ 11 .

Поскольку все другие ответы были адекватно предложены, вы можете использовать, __builtin_expectчтобы дать компилятору подсказку о том, как организовать код сборки. Как отмечают официальные документы , в большинстве случаев встроенный в ваш мозг ассемблер будет не так хорош, как ассемблер, созданный командой GCC. Для оптимизации кода всегда лучше использовать фактические данные профиля, а не гадать.

Аналогичным образом, но еще не упомянутым, существует специфичный для GCC способ заставить компилятор генерировать код по «холодному» пути. Это предполагает использование noinlineи coldатрибутов, которые делают именно то , что они звучат , как они делают. Эти атрибуты могут применяться только к функциям, но в C ++ 11 вы можете объявлять встроенные лямбда-функции, и эти два атрибута также могут применяться к лямбда-функциям.

Хотя это все еще попадает в общую категорию микрооптимизации, и поэтому применяется стандартный совет - тестируйте, а не угадайте - я считаю, что в целом он более полезен, чем __builtin_expect. Вряд ли какие-либо поколения процессоров x86 используют подсказки предсказания ветвления ( справочные ), поэтому единственное, на что вы все равно сможете повлиять, - это порядок кода сборки. Поскольку вы знаете, что такое код обработки ошибок или «пограничный» код, вы можете использовать эту аннотацию, чтобы гарантировать, что компилятор никогда не предскажет ответвление для него и свяжет его с «горячим» кодом при оптимизации по размеру.

Пример использования:

void FooTheBar(void* pFoo)
{
    if (pFoo == nullptr)
    {
        // Oh no! A null pointer is an error, but maybe this is a public-facing
        // function, so we have to be prepared for anything. Yet, we don't want
        // the error-handling code to fill up the instruction cache, so we will
        // force it out-of-line and onto a "cold" path.
        [&]() __attribute__((noinline,cold)) {
            HandleError(...);
        }();
    }

    // Do normal stuff
    ⋮
}

Более того, GCC автоматически проигнорирует это в пользу обратной связи профиля, когда она доступна (например, при компиляции с -fprofile-use).

См. Официальную документацию здесь: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__builtin_expect можно использовать, чтобы сообщить компилятору, в каком направлении должна идти ветвь. Это может повлиять на то, как генерируется код. Типичные процессоры последовательно запускают код быстрее. Итак, если вы напишете

if (__builtin_expect (x == 0, 0)) ++count;
if (__builtin_expect (y == 0, 0)) ++count;
if (__builtin_expect (z == 0, 0)) ++count;

компилятор сгенерирует код вроде

if (x == 0) goto if1;
back1: if (y == 0) goto if2;
back2: if (z == 0) goto if3;
back3: ;
...
if1: ++count; goto back1;
if2: ++count; goto back2;
if3: ++count; goto back3;

Если ваша подсказка верна, код будет выполнен без каких-либо фактически выполненных ветвей. Он будет работать быстрее, чем обычная последовательность, где каждый оператор if будет ветвиться вокруг условного кода и выполнять три ветви.

В новых процессорах x86 есть инструкции для ветвей, которые, как ожидается, будут выполняться, или для веток, которые, как ожидается, не будут выполняться (есть префикс инструкции; не уверен в деталях). Не уверен, что процессор использует это. Это не очень полезно, потому что с этим отлично справится предсказание ветвления. Поэтому я не думаю, что вы действительно можете повлиять на предсказание ветвления .

Что касается OP, нет, в GCC нет способа указать процессору всегда предполагать, что ветвь взята или не занята. У вас есть __builtin_expect, который делает то, что другие говорят. Кроме того, я думаю , вы не хотите сказать , процессор ли берется ветвь или не всегда . Современные процессоры, такие как архитектура Intel, могут распознавать довольно сложные шаблоны и эффективно адаптироваться.

Однако бывают случаи, когда вы хотите взять на себя управление тем, будет ли по умолчанию предсказано, что ветвление выполнено или нет: когда вы знаете, что код будет называться «холодным» в отношении статистики ветвления.

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

Другой пример: вы можете классифицировать свой ввод и перейти к коду, который обрабатывает результат вашей классификации. Если существует много классификаций, процессор может собирать статистику, но терять ее, потому что такая же классификация не происходит достаточно скоро, а ресурсы прогнозирования выделяются для недавно вызванного кода. Я бы хотел, чтобы был примитив, который говорил процессору «пожалуйста, не выделяйте ресурсы прогнозирования для этого кода», как иногда можно сказать «не кэшировать это».