Почему замена 0.1f на 0 замедляет код в 10 раз в Visual Studio 2010?

Корень проблемы: денормализованные числа и штраф за их обработку

Разница в производительности связана с тем, как процессор обрабатывает денормализованные (субнормальные) числа. Когда вы сравниваете float x = 1.0f с 0, результат false, и цикл продолжается. Но при сравнении с 0.1f компилятор генерирует код, который всегда даёт false (так как 1.0f < 0.1f ложно) и может оптимизировать проверку. Однако в реальном коде (например, с неконстантным x) ситуация меняется.

Главная проблема проявляется, когда x становится очень маленьким — в диапазоне денормализованных чисел (менее 1.17549e-38 для float). Операции с такими числами на x86/x64 могут быть в 10–100 раз медленнее из-за того, что процессор вынужден обрабатывать их микрокодом, а не аппаратно.

В вашем примере с константным x = 1.0f и сравнением с 0 компилятор может полностью удалить цикл, так как условие никогда не выполнится. Но если условие — if (x < 0.1f), то цикл тоже может быть удалён, так как 1.0f < 0.1f — всегда false. Разница в 10x возникает, когда код не оптимизируется так агрессивно, а процессор сталкивается с денормализованными числами.

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

Рассмотрим пример, где x изменяется:

float x = 1.0f;
for (int i = 0; i < 100000000; ++i) {
    x *= 0.5f;  // постепенно уменьшаем
    if (x < 0.1f) { ... }
}

После 120–150 итераций x станет денормализованным. Если в условии стоит 0, то сравнение x < 0 будет false (так как x положителен), но процессор всё равно будет обрабатывать денормализованное x при умножении, что замедляет код. Если же условие — x < 0.1f, то после перехода в денормализованную область условие станет true, и цикл может завершиться раньше, не вызывая дальнейших умножений.

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

• Отключить денормализованные числа через _controlfp (Windows):

#include <float.h>
_controlfp(_DN_FLUSH, _MCW_DN); // Flush-to-zero

• Использовать более новые инструкции SSE с флагом FTZ (Flush-To-Zero) и DAZ (Denormals-Are-Zero). В Visual Studio это можно сделать через /arch:SSE2 (по умолчанию) и включив _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON).
• Избегать очень малых чисел в циклах, если точность не критична.

Таким образом, замедление в 10x — это не баг компилятора, а особенность обработки денормализованных чисел процессором. При сравнении с 0 цикл может выполняться дольше, если код продолжает умножать денормализованные числа, а при сравнении с 0.1f — выходит из цикла раньше, избегая этой дорогой операции.