0.1f 与 0：为什么 C++ 代码会慢 10 倍以及如何修复

引言：一个代价为 10 倍性能的 Bug

想象一下这个场景：你正在编写高性能的 C++ 代码。一切运行如飞，测试通过，你感觉自己就是优化天才。然后你只更改了一个常量——将 0.1f 改为 0。性能就下降了 10 倍。不开玩笑，毫不夸张。正是这个问题在 Stack Overflow 上获得了数千次浏览，并成为那些想了解浮点数在处理器层面如何工作的人的经典案例。

在本文中，我们将分析为什么这个看似无害的替换会导致灾难，处理器内部的哪些机制对此负责，以及最重要的是——如何避免这种情况。本文对初级 C++ 开发人员和希望更深入了解 C++ 代码优化的经验丰富的工程师都很有用。

问题本质：非规格化数及其对 C++ 性能的影响

首先，让我们重现这个问题。考虑一个简单的浮点计算循环：

#include <iostream>\n#include <chrono>\n\nvoid slow_function(float factor) {\n    float sum = 0.0f;\n    for (int i = 0; i < 100000000; ++i) {\n        sum += factor * 0.1f;  // 如果 factor = 0.1f，则很快\n        // sum += factor * 0;  // 如果 factor = 0，则很慢\n    }\n    std::cout << sum << std::endl;\n}\n\nint main() {\n    auto start = std::chrono::high_resolution_clock::now();\n    slow_function(0.1f);  // 尝试将其替换为 0\n    auto end = std::chrono::high_resolution_clock::now();\n    std::cout << "Time: " \n              << std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count() \n              << " ms" << std::endl;\n    return 0;\n}

如果你用 factor = 0.1f 运行这段代码，执行时间大概是 100 毫秒。将其替换为 factor = 0，你就会得到 1000 毫秒或更多。相差 10 倍。为什么？

答案在于非规格化数。这是 C++ 优化中最棘手的陷阱之一，很少有人知道，除非他们亲身遇到。

什么是非规格化数，它们为什么会使代码变慢？

IEEE 754 浮点数标准不仅定义了规格化数（其中尾数以 1 开头），还定义了非规格化数（次正规数）。它们用于表示非常接近零的小值。当计算结果变得小于最小规格化数时，处理器会进入处理非规格化数的模式。

问题在于，x86 处理器对非规格化数的硬件支持非常慢。如果正常的 float 操作需要 1-3 个时钟周期，那么涉及非规格化数的操作可能需要 100-200 个或更多时钟周期。这就是性能下降的原因。

回到我们的例子。当 factor = 0.1f 时，所有中间结果都保持在规格化范围内。但是当 factor = 0 时，乘以零得到零。然后我们将 0.1f 加到零上——得到 0.1f。但在下一次迭代中，我们再次乘以零，再次得到零。如此反复数百万次。结果，处理器不断生成非规格化值，导致灾难性的减速。

实验：如何亲眼看到差异

让我们编写一个更直观的例子，展示非规格化数如何影响 C++ 代码的性能：

#include <iostream>\n#include <chrono>\n#include <cmath>\n\nvoid test_performance(float initial_value) {\n    float x = initial_value;\n    auto start = std::chrono::high_resolution_clock::now();\n    \n    for (int i = 0; i < 100000000; ++i) {\n        x = x * 0.5f + 0.1f;  // 典型的递推公式\n    }\n    \n