为何Rust线段碰撞检测函数中看似无用的if分支能提升性能？

我来帮你拆解这个有意思的性能现象——这种“无用代码反而加速”的情况在底层优化场景里其实挺常见的，结合你的Rust代码和测试结果，主要有这几个核心原因：

1. 给编译器传递了关键的语义提示 #

你添加的if dot == 0.0 { return false }分支，哪怕测试用例没触发它，也给编译器传递了一个明确的信息：后续代码执行时，dot绝对不会是0。

在没有这个分支的时候，编译器必须考虑dot=0的边界场景：此时dd = dot * dot也会是0，后续t和u的计算结果都会变成0，最后还要处理u >=0 && u <=0这类特殊比较。为了兼容这种情况，编译器会生成一些额外的浮点指令（比如你看到的unpcklpd/unpckhpd）来处理浮点运算的特殊情况，这些指令反而拖慢了正常路径的执行速度。

而有了这个分支后，编译器可以放心地针对dot非零的正常路径做激进优化：省略掉所有针对dot=0的边界处理逻辑，简化浮点运算的指令序列，甚至重新编排指令顺序来适配CPU的执行流水线。

2. 优化了CPU流水线的调度效率 #

现代CPU都是流水线架构，指令会被拆分成多个阶段并行执行。当编译器明确知道dot非零后，它可以调整后续浮点运算的指令布局，减少数据依赖或者指令停顿。

比如原本编译器可能因为要兼容dot=0的情况，把运算指令安排得比较保守（避免出现潜在的浮点异常风险），而去掉这个顾虑后，编译器可以重新排序指令，让CPU的浮点计算单元更高效地并行工作，减少流水线里的“气泡”（空闲周期），自然就能提升执行速度。

3. 关于Godbolt查看汇编的小技巧 #

你提到不知道怎么让rustc在Godbolt上不内联函数，其实很简单：给目标函数添加#[inline(never)]属性，强制编译器不做内联优化，就能看到两个函数各自独立的汇编代码了：

#[inline(never)]
fn line_line(a1x: f64, a1y: f64, a2x: f64, a2y: f64, b1x: f64, b1y: f64, b2x: f64, b2y: f64) -> bool {
    // 函数内容不变
}

#[inline(never)]
fn line_line_if(a1x: f64, a1y: f64, a2x: f64, a2y: f64, b1x: f64, b1y: f64, b2x: f64, b2y: f64) -> bool {
    // 函数内容不变
}

4. 额外的验证建议 #

你可以试试这几个操作来进一步确认原因：

• 测试dot=0的场景（比如两条平行线段），看看两个函数的性能差异是否反转（此时line_line_if会直接返回，应该远快于line_line）
• 在line_line函数里添加debug_assert!(dot != 0.0)，看看是否能获得和line_line_if类似的性能——这能验证编译器是否因为获得了dot非零的提示而优化
• 用cargo rustc --release -- --emit asm生成本地编译的汇编代码，直接对比两个函数的指令序列，重点看浮点运算部分的差异

总结一下：那个看似无用的if分支，本质上是给编译器传递了关键的优化提示，让它能针对正常执行路径生成更高效的机器码，最终带来了可观测的性能提升。

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