使用短路评估的好处 [英] Benefits of using short-circuit evaluation

查看:26
本文介绍了使用短路评估的好处的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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

In most languages, b will not get evaluated because a is false so a && b cannot be true. My question is, wouldn't short circuiting be slower in terms of architecture? In a pipeline, do you just stall while waiting to get the result of a to determine if b should be evaluated or not? Would it be better to do nested ifs instead? Does that even help?

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

Also, does anyone know what short-circuit evaluation is typically called? This question arose after I found out that my programming friend had never heard of short-circuit evaluation and stated that it is not common, nor found in many languages, and is inefficient in pipeline. I am not certain about the last one, so asking you folks!

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

Okay, I think a different example to perhaps explain where my friend might be coming from. He believes that since evaluating a statement like the following in parallel:

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

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

will crash the system, an architecture that doesn't have short-circuiting (and thereby not allowing statements like the above) would be faster in processing statements like these:

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

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

since if it couldn't do (a) in parallel, it can't do (b) in parallel. In this case, a language that allows short-circuiting is slower than one that does not.

我不知道这是不是真的.

I don't know if that's true or not.

谢谢

推荐答案

短路布尔表达式与一些嵌套的 if 完全等效,因此效率一样高.

Short-circuiting boolean expressions are exactly equivalent to some set of nested ifs, so are as efficient as that would be.

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

If b doesn't have side-effects, it can still be executed in parallel with a (for any value of "in parallel", including pipelining).

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

If b has side effects which the CPU architecture can't cancel when branch prediction fails then yes, this might require delays which wouldn't be there if both sides were always evaluated. So it's something to look at if you do ever find that short-circuiting operators are creating a performance bottleneck in your code, but not worth worrying about otherwise.

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

But short-circuiting is used for control flow as much as to save unnecessary work. It's common among languages I've used, for example the Perl idiom:

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

shell 习语:

do_something || echo "that failed"

或 C/C++/Java/etc 习惯用法:

or the C/C++/Java/etc idiom:

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

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

In all these cases you need short-circuiting, so that the RHS is only evaluated if the LHS dictates that it should be. In such cases there's no point comparing performance with alternative code that's wrong!

这篇关于使用短路评估的好处的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆