Почему поставить первым наиболее вероятное условие в if-else делает код шустрее на x86?

Потому что, внезапно, условия проверяются последовательно </thread>

Ты …, нехороший человек.
Сломал человеку картину мира. хнык…

Сломал человеку картину мира. хнык…

Для восстановления картины радужного мира с непоследовательным вычислением условий человек может принять живительного лиспа внутривенно

На уровне асма мир преображается https://godbolt.org/g/TVIk7Y более того, для первого условия выполняем еще +1 команду jmp. Но если воткнуть оптимизацию https://godbolt.org/g/cgFzoN то мне мало что понятно, такие инструкции мы не проходили ) И, ой, тут всё не последовательно...

P.S. Предполагалось, что хром применит JIT для функции со 100 000 000 вызовами.

А на уровне современного процессора, так вообще неясно в какой последовательности там исполнится код.

Посмотрел -O2 код. Условно (на самом деле, там стремная магия, но для сути подойдет):

1) Прибавляем к первому аргументу 11, кладем в возврат

2) Прибавляем ко второму аргументу 10

3) Проводим тестирование

4) Если оригинал равен нулю, перетираем возврат вторым аргументом

Последовательность действий просто железная

то мне мало что понятно, такие инструкции мы не проходили

Наводи курсор мыши, там в твоей штуке есть справка по командам

Неясно, только если код прямой как рельса. Там OoO может развернуться.

А то, о чём пишешь ты - это оптимизация бранчинга, чтоб помочь предсказателю переходов.

А на уровне современного процессора, так вообще неясно в какой последовательности там исполнится код.

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

if (ptr == NULL ) {
  return ERROR_BIG_SHIT;
} else if (ptr.coco == 1) {
  // do smth...
}

Т.е. компилятор просто обязан обеспечивать очередность проверки.

Внутри условий сейм щит, с таким же обоснованием:

if (ptr != NULL && ptr.coco == 1);

Так что мой ответ из первого коммента остается в силе.

Правда, при всяких -O3 и уверенности компилятора в себе это иногда может и не работать. Но тут я не уверен, это место может быть описано в стандарте как обязательное.

Касательно последнего примера - Стандарт гарантирует, что условия будут вычисляться слева направо.

Почему так?

Потому что жадная логика, не?

никогда не видел конструкции, типа:

if (pObj && pObj->state() == 42) {
    // do smth
} 

P.S. Предполагалось, что хром применит JIT для функции со 100 000 000 вызовами.

Магия не всесильна.

погугли likely/unlikely.

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

http://yarchive.net/comp/linux/cmov.html

Подожите, так разве блок предсказания ветвлений в процессорах отменили что ли?

предсказывают поди как то...