算法效率怪事：运算步骤更多的公式为何速度更快？

我近期写了一段用于生成0-1区间平滑值的代码，测试了两种数学上等价的实现，发现运算步骤更多的Sin版本反而比Cos版本快约31%。

两种实现代码：
Sin版本（4步运算）

_ = (Mathf.Sin(-1.57079633f + (time * 3.14159265f)) + 1) * 0.5f;

Cos版本（3步运算）

_ = Mathf.Cos(time * 3.14159265f) * -0.5f + 0.5f;

测试条件：time取常量0.5f，已排除Sin/Cos函数本身算法差异的影响，测试System.Math API也得到类似结果，仅System.Math因double转float整体略慢。

附测试代码：

var sw = new System.Diagnostics.Stopwatch();
sw.Start();
for (int i = 0; i < 500000; i++)
{
    _ = (Mathf.Sin(-1.57079633f + (time * 3.14159265f)) + 1) * 0.5f; // Sin + 4o
}
sw.Stop();
print($"Sin calc time = {sw.ElapsedTicks * 0.0001f}ms ({sw.ElapsedMilliseconds}ms)");
sw.Restart();
for (int i = 0; i < 500000; i++)
{
    _ = Mathf.Cos(time * 3.14159265f) * -0.5f + 0.5f; // Cos + 3o
}
sw.Stop();
print($"Cos calc time = {sw.ElapsedTicks * 0.0001f}ms ({sw.ElapsedMilliseconds}ms)");

可能的性能差异原因 #

1. 常量折叠与特殊值优化 #

你的测试中time是常量0.5f，编译器可以提前计算部分表达式：

• Sin版本里的-1.57079633f + (0.5f * 3.14159265f)结果接近0，很多数学库对Sin(0)这类特殊值有硬编码的快速路径，直接返回结果，跳过了完整的三角函数计算流程。
• 而Cos版本里的输入是π/2，虽然也是特殊值，但部分库对Cos的特殊值优化优先级更低，或者其快速路径的开销比Sin(0)略高。

2. CPU指令级差异 #

x86/x64架构的CPU有专门的三角函数指令（如FSIN/FCOS、VSINPS/VCOSPS），但这些指令的执行周期并不完全相同：

• 部分CPU上，FSIN处理接近0的输入时，延迟比FCOS处理π/2输入更低。
• 现代CPU的指令调度可能对Sin相关指令的吞吐量更友好，或者代码触发了微架构层面的优化（比如指令融合、缓存命中差异）。

3. Unity Mathf的实现细节 #

Unity的Mathf.Sin和Mathf.Cos采用了近似算法（比如泰勒展开、CORDIC算法），而非直接调用CPU指令。可能Sin的近似算法在输入接近0时收敛速度更快，计算步骤更少；而Cos在输入接近π/2时，需要更多迭代或更复杂的校正步骤。

验证建议 #

可以尝试改变time的值（比如取0.1f、0.3f等非特殊值）重新测试。如果Sin版本的优势消失或大幅缩小，说明是特殊值优化导致的差异；如果优势依然存在，大概率是CPU指令或库实现本身的性能差异。

内容的提问来源于stack exchange，提问作者CBX_MG