Странное различие в производительности C++?

Возможно, результатом getFreq будет хранится в регистре в первом случае и записывается в память во втором случае? Также может быть, что снижение производительности связано с механизмами ЦП, такими как конвейерная обработка и / или прогнозирование ветвлений. Вы можете проверить сгенерированный код сборки.

По-моему, это похоже на остановку трубопровода

int iFreq = getFreq(i);
    double dFreq = iFreq;

    if (iFreq != 0) {

Позволяет преобразование в двойное параллельно с другим кодом. так как dFreq используется не сразу. Это дает компилятору что-то. между хранением iFreq и его использованием, так что это преобразование, скорее всего. "Свободный".

Но

int iFreq = getFreq(i);

if (iFreq != 0) {
    // do some stuff with iFreq...
    double dFreq = iFreq;
    // do some stuff with dFreq...
}

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

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

Компиляторы C++ довольно хорошо умеют переупорядочивать инструкции, чтобы воспользоваться этим, похоже, что ваше изменение одержало победу над какой-то хорошей оптимизацией.

Еще одна (менее вероятная) возможность состоит в том, что когда преобразование в float было до ветки, компилятор смог полностью удалить ветку. Код без ветки часто является серьезным выигрышем в производительности современных процессоров.

Было бы интересно посмотреть, какие инструкции на самом деле выдал компилятор для этих двух случаев.

Попробуйте перенести определение dFreq за пределы цикла for, но сохраните задание внутри блока for loop/if.

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

double dFreq;
int iFreq;
for (int i = 0; i < ct; ++i) 
{
    // do some stuff...

    iFreq = getFreq(i);

    if (iFreq != 0) 
    {
        // do some stuff with iFreq...
        dFreq = iFreq;
        // do some stuff with dFreq...
    }
} 

возможно, компилятор оптимизирует его, выводя определение за пределы цикла for. когда вы помещаете его в if, оптимизация компилятора этого не делает.

Есть вероятность, что это изменение привело к тому, что ваш компилятор отключил некоторые оптимизации. Что произойдет, если вы переместите объявления над циклом?

Это достаточно легко узнать. Просто сделайте 20 стеков медленной версии и быстрой версии. В медленной версии вы увидите примерно на двух кадрах то, что она делает, чего не делает в быстрой версии. Вы увидите небольшую разницу в том, где он останавливается на языке ассемблера.

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

В этой статье (немного старой, но вполне достоверной) говорится (со статистикой) нечто подобное: http://www.tantalon.com/pete/cppopt/asyougo.htm#PostponeVariableDeclaration