Почему замена 0.1f на 0 в цикле замедляет код в 10 раз (C++, VS2010)?

Причина: денормализованные числа (denormals) и аппаратное исключение

Вы столкнулись с классическим эффектом, связанным с обработкой денормализованных чисел (subnormal/denormal numbers) в процессорах x86/x64. Когда вы умножаете int на 0.1f, результат никогда не становится денормализованным — числа остаются в нормальном диапазоне. Но когда вы умножаете на 0, происходит следующее:

1. i * 0 даёт целочисленный ноль.
2. При приведении к float получается 0.0f.
3. Далее x = 0.0f, и x * x даёт 0.0f.
4. Но! В первом же проходе цикла sum становится 0.0f. После этого все последующие операции sum += 0.0f — это сложение нуля с нулём.

Проблема в том, что аппаратное обеспечение (FPU/SSE) обрабатывает операции с денормализованными числами (в данном случае — с нулём, который является частным случаем денормализованного) медленнее. На процессорах Intel до Haswell (и на многих AMD) операции с денормализованными числами могут занимать в 10–100 раз больше тактов, чем с нормальными числами. Когда sum и x равны нулю, FPU переходит в режим обработки "gradual underflow" (постепенное исчезновение значимости), что вызывает микроисключения (microcode assists).

Почему с 0.1f такого не происходит?

При умножении на 0.1f переменная x принимает значения типа 0.1, 0.2, 0.3, ... — все они являются нормальными числами (нормализованными). Сумма sum растёт, и никогда не достигает нуля. Следовательно, FPU работает в нормальном режиме.

Как это исправить?

Есть два основных решения:

1. Использовать флаг компилятора для отключения обработки денормализованных чисел (flush-to-zero):

// Для MSVC (VS2010):
_controlfp(_DN_FLUSH, _MCW_DN); 
// Или через intrinsic:
_mm_setcsr(_mm_getcsr() | 0x8000); // DAZ + FTZ

2. Изменить логику, чтобы избежать нулевых значений:

float sum = 0.0f;
for (int i = 0; i < 100000000; ++i) {
    float x = i * 0; 
    // Принудительно обнуляем sum, чтобы избежать денормалов:
    if (x == 0.0f) continue; 
    sum += x * x;
}
// Но это не решит проблему, если sum уже стал нулём.
// Лучше:
if (sum == 0.0f) break; // Выход из цикла, так как все последующие итерации дадут 0

3. Использовать целочисленную арифметику, если результат гарантированно ноль:

// Если вы знаете, что результат будет нулевым, просто не пишите цикл:
float sum = 0.0f; // сразу присвойте ноль

Дополнительная информация

• Denormals-are-zero (DAZ) — режим, при котором денормализованные числа приравниваются к нулю. Включается через _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON).
• Flush-to-zero (FTZ) — результат операции, который должен быть денормализованным, принудительно становится нулём.
• В современных процессорах (Skylake и новее) эта проблема менее выражена, но на старых (Core 2, Nehalem, Sandy Bridge) разница может быть драматической.

Таким образом, ваш код не медленнее из-за умножения на ноль — он медленнее из-за того, что FPU тратит время на обработку денормализованных чисел, которые возникают при сложении нуля с нулём. Это известное поведение, и оно не является багом компилятора.

// Включение FTZ и DAZ на MSVC:
#include <float.h>
_controlfp(_DN_FLUSH, _MCW_DN); // FTZ
_controlfp(_DN_UNDERFLOW, _MCW_EM); // DAZ (необязательно)