Доброго дня,
интересует вопрос — какой вариант скорее всего будет работать более быстро в современных реализациях компиляторов:

// Вариант 1.
if ( condition ) {
   DoSmth1();
   return;
} else {
   DoSmth2();
}

// Вариант 2.
if ( condition ) {
   DoSmth1();
   return;
}

DoSmth2();

То есть, в случае невыполнения condition в каком из двух вариантов DoSmth2() будет вызвана быстрее. Компиляция со включенной оптимизацией по скорости.

Здравствуйте, RSDN_new_user, Вы писали:


RSD>То есть, в случае невыполнения condition в каком из двух вариантов DoSmth2() будет вызвана быстрее. Компиляция со включенной оптимизацией по скорости.

абсолютно одинаково

Здравствуйте, RSDN_new_user, Вы писали:

RSD>Доброго дня,
RSD>интересует вопрос — какой вариант скорее всего будет работать более быстро в современных реализациях компиляторов:

то есть по-твоему все тормоза программы в это упираются?

Здравствуйте, RSDN_new_user, Вы писали:

RSD>Доброго дня,
RSD>интересует вопрос — какой вариант скорее всего будет работать более быстро в современных реализациях компиляторов:

По скорости разницы не будет.

RSD>То есть, в случае невыполнения condition в каком из двух вариантов DoSmth2() будет вызвана быстрее. Компиляция со включенной оптимизацией по скорости.
Ты можешь передать компилятору информацию о приоритете веток, если по какой-то причине у тебя нет возможности использовать profile-guided-optimization.
Например, в gcc это делается через __builtin_expect (у других компиляторов — другое название) так:

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

if ( unlikely(condition) ) {
   DoSmth1();
   return;
} else {
   DoSmth2(); // эта ветка будет иметь приоритет.
}

Если посмотреть на сгенерированный ассемблерный код, то в новом варианте вызов функции DoSmth2 будет происходить в некоторых случаях чуть-чуть быстрее (разумеется, с соответствующим увеличением задержки перед вызовом DoSmth1).
Но вообще, влияние __builtin_expect ограничено довольно специфическими ситуациями, так что явно ими управлять редко бывает необходимым.

Здравствуйте, Anpek, Вы писали:

A>то есть по-твоему все тормоза программы в это упираются?

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

Здравствуйте, RSDN_new_user, Вы писали:

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

нужно руководствоваться читабельностью а не производительностью

Здравствуйте, RSDN_new_user, Вы писали:

RSD>То есть, в случае невыполнения condition в каком из двух вариантов DoSmth2() будет вызвана быстрее. Компиляция со включенной оптимизацией по скорости.

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

Здравствуйте, RSDN_new_user, Вы писали:

RSD>По-моему, я могу использовать оба варианта, не заметив разницы. И если бы один из них был хотя бы чуть быстрее, то почему бы не использовать всегда его.

Благими намерениями вымощена дорога к преждевременной оптимизации. Так говорил Зарадейкстра.

Здравствуйте, watch-maker, Вы писали:

WM>Например, в gcc это делается через __builtin_expect (у других компиляторов — другое название) так:

AFAIK у MSVC такого флага нет () , оно управляется через Profile Guided Optimization настройку проекта.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, RSDN_new_user, Вы писали:

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

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

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

Короче, совет — бросить заниматься фигней.
Ну и в конце концов — если уж так хочется убедиться — что же все таки быстрее и на сколько — разве сложно сделать тест? Запустить условия в цикле, и замерять время? Только условия конечно же должны каждый раз меняться, чтобы компилятор не вынес их за пределы цикла.

Здравствуйте, vl690001x, Вы писали:

RSD>>>То есть, в случае невыполнения condition в каком из двух вариантов DoSmth2() будет вызвана быстрее. Компиляция со включенной оптимизацией по скорости.
V>>В данном варианте неизвестно, но есть вариант что первым надо писать условие которое чаще выполняться будет, т.к. промах по условию — лишние такты. Но это в случае если компилятор не будет хитрить и сгенерирует примерно такой же набор ассемблерных условий в той же последовательности.
V>А тут всего одно условие, оно в любом случае выполняется, а потом в любом случае выполняется переход или в одно место программы, или в другое.
ну так в cisc переход вроде и медленнее будет неперехода

V>Вообще, программируя на Си, это не тот вопрос о котором следует задумываться, такие микроскопические и банальные оптимизации должен делать компилятор.
Это если это не какой-нить древний компилятор типа gcc 2.95