Подсказки прогнозирования переносимых переходов

Канонический способ предсказания статического перехода заключается в том, что if предсказывается без ветвления (т. е. выполняется каждое предложение if, а не else), а также выполняются циклы и goto назад. Итак, не помещайте общий случай в else, если вы ожидаете, что статический прогноз будет значительным. Обойти незанятый цикл не так просто; Я никогда не пробовал, но я полагаю, что предложение else должно работать довольно переносимо.

Многие компиляторы поддерживают ту или иную форму #pragma unroll, но для защиты других компиляторов по-прежнему необходимо защищать ее каким-либо видом #if.

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

Как рекомендует GNU в документации для __builtin_expect, оптимизация по профилю лучше, чем подсказки, и с меньшими усилиями.

В большинстве случаев следующий код

if (a)
{
   ...
}
else
{
    ...
}

на самом деле

evaluate(A)

if (!A)
{
   jmp p1
}

... code A

   jmp p2

p1:

... code !A

p2:

Обратите внимание, что если A истинно, «код A» уже находится в конвейере. Процессор увидит впереди команду «jmp p2» и загрузит код p2 в конвейер.

Если A имеет значение false, «код !A» может отсутствовать в конвейере, поэтому он может работать медленнее.

Выводы:

1. do If(X), если X более вероятен, чем !X
2. постарайтесь оценить A как можно раньше, чтобы ЦП мог динамически оптимизировать конвейер.

:

evaluate(A)

do more stuff

if (A)
   ...

Оптимизация по своей сути является компилятором, поэтому вы должны использовать функциональность компилятора, чтобы помочь ей. Сам язык не заботится (или не требует) об оптимизации.

Таким образом, лучшее, что вы можете сделать без расширений, специфичных для компилятора, — это организовать свой код таким образом, чтобы ваши компиляторы «делали правильные вещи» без посторонней помощи. Но если вы хотите быть уверенным, подключитесь к расширениям компилятора. (Вы можете попробовать абстрагировать их за препроцессором, чтобы ваш код оставался переносимым.)

C++20 предлагает вероятные и маловероятные атрибуты

Разрешить компилятору оптимизировать для случая, когда пути выполнения, включающие этот оператор, более или менее вероятны, чем любой альтернативный путь выполнения, который не включает такой оператор

Просто будьте последовательны в том, что вы делаете. мне нравится использовать

if (!(someExpression))

Но компилятор должен относиться к этому одинаково.

Что плохого в проверке конкретного компилятора через #ifdef и сокрытии этих вещей за пользовательским макросом? Вы можете #define расширить его до простого выражения, если у вас нет компилятора, поддерживающего эти подсказки по оптимизации. Недавно я сделал что-то подобное с явной предварительной выборкой кеша, которую GCC поддерживает с помощью встроенной функции.