architecture - 使用短路评估的好处

Question

boolean a = false, b = true;
if ( a && b ) { ... };

在大多数语言中， b不会被评估，因为 a所以是假的 a && b不可能是真的。我的问题是，就架构而言，短路不会更慢吗？在管道中，您是否只是在等待获得 a 的结果以确定是否应评估 b 时停止？改为使用嵌套 if 会更好吗？这甚至有帮助吗？

另外，有谁知道短路评估通常被称为什么？这个问题是在我发现我的编程 friend 从未听说过短路评估并说它不常见，在许多语言中都没有，并且在管道中效率低下之后出现的。我不确定最后一个，所以问你们!

好吧，我想一个不同的例子来解释我的 friend 可能来自哪里。他认为，由于并行评估如下语句:

(a) if ( ( a != null ) && ( a.equals(b) ) ) { ... }

会使系统崩溃，没有短路(因此不允许上述语句)的架构在处理以下语句时会更快:

(b) if ( ( a == 4 ) && ( b == 5 ) )

因为如果它不能并行执行(a)，它就不能并行执行(b)。在这种情况下，允许短路的语言比不允许短路的语言慢。

我不知道这是不是真的。

谢谢

Answer 1

短路 bool 表达式完全等同于一组嵌套的 if，因此效率一样高。

如果 b 没有副作用，它仍然可以与 a 并行执行(对于“并行”的任何值，包括流水线)。

如果 b 具有在分支预测失败时 CPU 架构无法取消的副作用，那么是的，这可能需要延迟，如果总是评估双方，则不会存在延迟。因此，如果您确实发现短路操作符在您的代码中造成了性能瓶颈，那么值得关注，但不值得担心。

但是短路用于控制流程，以节省不必要的工作。这在我使用过的语言中很常见，例如 Perl 习语:

open($filename) or die("couldn't open file");

shell 成语:

do_something || echo "that failed"

或 C/C++/Java/etc 成语:

if ((obj != 0) && (obj->ready)) { do_something; } // not -> in Java of course.

在所有这些情况下，您都需要短路，以便 RHS 仅在 LHS 指示应该如此时才进行评估。在这种情况下，将性能与错误的替代代码进行比较是没有意义的!