Использование bools в расчетах, чтобы избежать веток

Does the second version avoid a branch

если вы скомпилируете свой код, чтобы получить вывод на ассемблере, g++ -o test.s test.cpp -Sвы обнаружите, что во второй функции ветки действительно избегают.

and consequently, is faster than the first version

я выполнял каждую из твоих функций 2147483647 или же INT_MAX количество раз, когда в каждой итерации я случайно назначил логическое значение running член вашего Timer структура, используя этот код:

int main() {
const int max = std::numeric_limits<int>::max();
timestamp_t start, end, one, two;
Timer t_one, t_two;
double percent;

srand(time(NULL));

start = get_timestamp();
for(int i = 0; i < max; ++i) {
t_one.running = rand() % 2;
t_one.step_versionOne(1);
}
end = get_timestamp();
one = end - start;

std::cout << "step_versionOne      = " << one << std::endl;

start = get_timestamp();
for(int i = 0; i < max; ++i) {
t_two.running = rand() % 2;
t_two.step_versionTwo(1);
}
end = get_timestamp();
two = end - start;

percent = (one - two) / static_cast<double>(one) * 100.0;

std::cout << "step_versionTwo      = " << two << std::endl;
std::cout << "step_one - step_two  = " << one - two << std::endl;
std::cout << "one fast than two by = " << percent << std::endl;
}

и вот результаты, которые я получил:

step_versionOne      = 39738380
step_versionTwo      = 26047337
step_one - step_two  = 13691043
one fast than two by = 34.4529%

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

В общем, хороший вопрос, я кое-что узнал сегодня!

БОЛЬШЕ:

конечно, случайно генерируя runningПо сути, мы делаем предсказание ветвления бесполезным в первой функции, поэтому приведенные выше результаты не слишком удивительны. однако, если мы решим не изменять running во время итераций цикла и вместо этого оставьте значение по умолчанию, в этом случае falseПредсказание ветвлений сделает свою магию в первой функции и на самом деле будет быстрее почти на 20%, как показывают эти результаты:

step_versionOne      = 6273942
step_versionTwo      = 7809508
step_two - step_one  = 1535566
two fast than one by = 19.6628

так как running постоянна на протяжении всего выполнения, обратите внимание, что время моделирования намного короче, чем при случайном изменении running — вероятно, результат оптимизации компилятора.

почему вторая функция медленнее в этом случае? хорошо, предсказание ветвления быстро поймет, что условие в первой функции никогда не будет выполнено, и поэтому остановит проверку в первую очередь (как будто if(running) ticks += mStepSize; даже не там). с другой стороны, второй функции все равно придется выполнять эту инструкцию ticks += mStepSize * static_cast<int>(running); в каждой итерации, что делает первую функцию более эффективной.

но что если мы установим running в true? хорошо, предсказание ветвится снова, однако, на этот раз, первая функция должна будет оценить ticks += mStepSize; в каждой итерации; здесь результаты, когда running{true}:

step_versionOne      = 7522095
step_versionTwo      = 7891948
step_two - step_one  = 369853
two fast than one by = 4.68646

заметить, что step_versionTwo занимает одинаковое количество времени, будь то running постоянно true или же false, но это все еще занимает больше времени, чем step_versionTwo, однако незначительно. ну, это может быть потому, что я слишком ленив, чтобы запускать его много раз, чтобы определить, является ли он стабильно быстрым или одноразовым (случайные результаты немного меняются при каждом запуске, поскольку ОС должна работать в фоновом режиме). и это не всегда будет делать то же самое). но если это постоянно быстрее, это может быть потому, что функция два (ticks += mStepSize * static_cast<int>(running);) имеет арифметический оп больше, чем функция один (ticks += mStepSize;).

наконец, давайте скомпилируем с оптимизацией — g++ -o test test.cpp -std=c++11 -O1 и давайте вернемся running вернуться к false а затем проверьте результаты:

step_versionOne      = 704973
step_versionTwo      = 695052

более или менее то же самое. компилятор выполнит этап оптимизации и реализует running всегда false и, таким образом, для всех намерений и целей удалит тело step_versionOneпоэтому, когда вы вызываете его из цикла в main, он просто вызовет функцию и вернется.

с другой стороны, при оптимизации второй функции он поймет, что ticks += mStepSize * static_cast<int>(running); всегда будет генерировать один и тот же результат, т.е. 0так что это тоже не будет беспокоить.

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

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

step_versionOne      = 18868782
step_versionTwo      = 18812315
step_two - step_one  = 56467
one fast than two by = 0.299261