Существуют ли реальные примеры, где использование [[likely]] и [[unlikely]] приводит к улучшению производительности?

У тебя лапки? Напиши бенчмарк и посмотри. На худой конец попроси чатгопоту написать бенчмарк.

производительность или нет, но например размер бинаря уменьшить может

в гугле забанили?

https://easyperf.net/blog/2018/07/09/Improving-performance-by-better-code-locality

При чтении новых топиков все чаще возникает ощущение, что это промпт

Дорогой, проснись! Тебя подключили к машине для решения задач, которые она тебе подсовывает под видом вопросов в интернете и синтетического быта! Мы ждём тебя дома!

Могу предположить, что для e2k будет польза

это такое в новом C++?

Как вообще это всё можно запихать в голову человека, который начинает учить плюсы? =)

И кстати, когда будет [[highly likely]] ?

Во первых ты можешь логически подумать и выставить if/else в порядке том, который наиболее вероятен. Если при этом ты выставить условиям ещё likely и unlikely то компилятор сделает свои дополнительные действия в сторону того что поддержать твои предположения оптимизациями. В конечном итоге всё зависит от того в каких условиях будет выполнятся программа, если например открытие файла в 99% вероятности будет успешным, то и потуги компилятора в эту сторону будут выгодны, если таже самая программа столкнётся с тем что 99% превратятся в 9% и файл будет часто открываться с ошибой (пробелемы с правами файла например) то либо просто всё останется как есть или оптимизации компилятора превратятся в накладные расходы. Вот и всё.

Иной пример, ты в игре расчитываешь столкновения пересечения луча с объектом на в сцене, есть условие что если начало луча по Y отрицательное то игрок провалился под карту и его надо выкинуть на верх, игроки редко проваливаются под карту и следовательно при наличии других услорвий предвычислить тела веток лучше там и продолжить их выполнять когда условия сойдётся, а уже только тогда когда значение Y ушло в минус выполнять на холодную код который за это отвечает.

Ветки в if/else могут быть частично выполнены ещё до срабатывания условий, эта оптимизация нгаправлена на то чтобы предвыполнялась та ветка которая наиболее вероятна. Если работа программы совпадает с ожиданиями будет прирост производительности, если не совпала, то часто нет ни прироста ни падания. Так что просто подумай логически и проставь вероятности линей унликей и всё. Делов две секунды, при хороших условиях будет быстрее, при плохих будет также.

Добро пожаловать в профайлинг :)

У тебя есть возможность подсказать компилятору на сколько вероятно условие.
Полезно для условных действий в коде который выполняется много раз (цикл или функция выполняемая очень часто).

У gcc есть вариант оптимизации для ленивых (-fprofile-generate & -fprofile-use) что даёт ускорения до 20%.

оптимизации для ленивых (-fprofile-generate & -fprofile-use)

Это сколько же у ленивых прыти организовать двухстадийный пайплайн сборки-выкатки…

Слышал истории про то, что при генерации кода из решающих деревьев бывает полезно с подобными атрибутами играться, но в целом в обычном, написанном людьми, коде доводилось видеть скорее ухудшение, когда unlikely-ветка (оказавшаяся не такой уж unlikely) была пессимизирована. По-моему, PGO (как встроенное в компилятор, так и тулы типа BOLT) решают задачу куда полнее и точнее, и если уж хочется выжимать перформанс из кодогенерации, то имеет смысл сразу в эту сторону смотреть.

И кстати, когда будет [[highly likely]] ?

__builtin_expect_with_probability уже сто лет в обед как есть.

Профайлите и обрящете.

Из личного опыта (High Frequency Trading, но не тот, где за наносекунды борются, а за микро) скорее контр-пример.

• расставляли likely - unlikely по критическому пути, измеримых результатов не увидели
• использовали -fprofile-generate & -fprofile-use, получили измеримое замедление
• основной реальный способ ускорения - оптимизации обращения к кешу (как расположение данных, так и прогрев кешей).

В виде атрибутов это уже давно есть в Си и активно юзается в ядре Linux.