> Именно так. OOO, предсказание переходов, спекулятивное выполнение.
> На уровне компилятора это НЕ делается.
> Хоть с likely, хоть с unlikely, хоть с highly likely.
> Потому что реальные данные известны только на момент выполнения, соответственно и результат
> кондишнла.Глупости. Процессор знаешь как делает? Он декодирует инструкцию условного перехода, он не может её выполнить сразу, потому что FLAGS ещё не готовы, чтобы знать как её выполнять, поэтому он делает "предсказание", сводящееся к следующему:
если условный переход имеет отрицательный аргумент (смещение в байтах которое надо приплюсовать к текущему значению IP -- instruction pointer), то он выполнится, если переход с положительным аргументом, то он не выполнится.
Вот и всё ясновидение в CPU. Оно заточено под циклы, которые как правило заканчиваются инструкцией "jnz my_loop" или типа того: поскольку переход выполняется в сторону меньших адресов, то аргумент к jnz оказывается отрицательным, и поэтому процессор его "предсказывает" как выполняющийся, и спекулятивно начинает выполнять тело цикла ещё раз, до того, как посчитает условие, которое выставит флаги для jnz.
Переход вперёд рассматривается как unlikely, зачем-то. Я предполагаю, для того, чтобы была возможность оптимизировать unlikely переходы под этот тупой предсказатель, без инверсии условия, которая требует ещё одной команды.
likely/unlikely лишь располагает ветви if'а таким образом, чтобы likely переход выполнялся бы назад, а unlikely вперёд. То есть _оптимизация_ происходит в compile-time, код располагается таким образом, чтобы "предсказания" процессора были бы верными.
> Как только встретился кондишнл - всё, нет больше конвеера, ждём да/нет/не знаю (чёрный юмор) от такового.
Нет, не ждём, а включаем предсказания и спекулятивное выполнение.
> Потому что реальные данные известны только на момент выполнения, соответственно и результат кондишнла.
Реальные данные могут изменить лишь то, что unlikely переходы иногда всё же выполняются, а likely иногда не выполняются, и в таком случае предсказания процессора оказываются неверными и все результаты достигнутые в результате спекулятивного выполнения надо выкинуть. Скажем любой цикл (где в конце тела есть условный переход назад, на начало цикла) приводит к одному misprediction, к одному сфейлившемуся предсказанию, которым собственно цикл заканчивается. Единственный способ избежать этого -- отправить на выполнение вычисление условия продолжения цикла до того, как на выполнение ушло тело цикла, тогда есть шансы, что когда процессор доберётся до команды условного перехода, условие уже будет посчитано, и тогда процессору не придётся полагаться на свои предсказания. Но для того, чтобы это работало, придётся результаты расчётов условия хранить не в регистре FLAGS, который глобальный для всех команд, и который будет перезаписан командами тела цикла, а в каком-нибудь другом регистре.
upd. Глупость сморозил: "предполагаю, для того, чтобы была возможность оптимизировать unlikely переходы под этот тупой предсказатель, без инверсии условия, которая требует ещё одной команды". Там не нужна ещё одна команда, можно инвертировать условие команды условного перехода. То есть я вообще без идей, зачем это надо.
