C# 使用“大于或等于”或只是“大于”

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/231159/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-03 19:07:29  来源:igfitidea点击:

Use "greater than or equals" or just "greater than"

c#.netc

提问by Guy

I remember from C days that we were encouraged to use

我记得从 C 天开始,我们被鼓励使用

i > -1

instead of

代替

i >= 0

because of performance.

因为性能。

Does this still apply in the C# .NET world? What are the performance implications of using one over the other with today's compilers? i.e. Is the compiler clever enough to optimize these for you?

这仍然适用于 C# .NET 世界吗?在当今的编译器中使用一种对另一种的性能影响是什么?即编译器是否足够聪明来为您优化这些?

(As an aside try and type the question "use >= or >" into the question field on Stack Overflow and see what happens.)

(顺便说一句,尝试在 Stack Overflow 的问题字段中输入问题“use >= or >”,看看会发生什么。)

采纳答案by Dan Lenski

No, there are no performance issues associated with comparison operators. And any good compiler would optimize something this trivial anyway.

不,没有与比较运算符相关的性能问题。无论如何,任何好的编译器都会优化这种微不足道的东西。

I'm not sure where you got the suggestion to use "i > -1" rather than "i >= 0". On the x86 architecture, it makes no difference which you use: either case takes exactly two instructions... one to compare and one to jump:

我不确定您从哪里得到使用“i > -1”而不是“i >= 0”的建议。在 x86 体系结构上,使用哪种方法没有区别:任何一种情况都只需要两条指令……一条进行比较,一条进行跳转:

 ;; if (i > -1) {
 cmp eax, -1
 jle else
then:
 ...
else:

 ;; if (i >= 0) {
 cmp eax, 0
 jl else
then:
 ...
else:

On most RISC architectures that I know, "i >= 0" may actually be faster since there is usually a dedicated zero register, and "i > -1" may require loading a constant. For example, MIPS only has a < instruction (no <=). Here is how the two constructs would be (naively!) expressed in MIPS assembly language:

在我知道的大多数 RISC 架构上,“i >= 0”实际上可能更快,因为通常有一个专用的零寄存器,而“i > -1”可能需要加载一个常量。例如,MIPS 只有 < 指令(没有 <=)。以下是这两个结构将如何(天真地!)用 MIPS 汇编语言表达:

 // if (i >= 0) {   (assuming i is in register %t0)

 stl $t1, 
if (length >= str.size())
, $t0 // in C: t1 = (0 < t0) beq $t1,
if (length > str.size() - 1)
, else // jump if t1 == 0, that is if t0 >= 0 nop then: ... else: // if (i > -1) { (assuming i is in register %t0) addi $t2, ##代码##, -1 // in C: t2 = -1 stl $t1, $t2, $t0 // in C: t1 = (t2 < t0) = (-1 < t0) bne $t1, ##代码##, else // jump if t1 != 0, that is if t0 > -1 nop then: ... else:

So in the naive, general case, it will actually be one instruction faster to do "i >= 0" on MIPS. Of course, RISC code is so heavily optimizable that a compiler would likely change either of these instruction sequences almost beyond recognition :-)

因此,在一般情况下,在 MIPS 上执行“i >= 0”实际上会快一条指令。当然,RISC 代码的优化程度如此之高,以至于编译器可能会更改这些指令序列中的任何一个,几乎无法识别:-)

So... the short answer is no no no, no difference.

所以......简短的回答是不不不,没有区别。

回答by Epaga

No you don't need to do this any more. Yes the compilers have become much smarter and the two expressions have no performance differences.

不,你不需要再这样做了。是的,编译器变得更聪明了,两个表达式没有性能差异。

回答by James Curran

I remember from C days that we were encouraged to use .... because of performance.

我记得从 C 时代起,我们就被鼓励使用 .... 因为性能。

Are you sureabout that? I've worked with computers going back to the early '70's (yes, at my father's knee...), and I've never seen a CPU that couldn't process >= just as fast as >. (BH "Branch High" vs. BNL "Branch Not Low" in IBM360 talk).

确定吗?我曾使用可追溯到 70 年代初的计算机(是的,在我父亲的膝盖上......),我从未见过不能像 > 一样快地处理 >= 的 CPU。(IBM360 谈话中的 BH“Branch High”与 BNL“Branch Not Low”)。

回答by Jon Skeet

There is a very similar question (no criticism implied - as you say, searching for symbols is tricky) here: "Should one use <or <=in a for loop"

这里有一个非常相似的问题(没有暗示批评 - 正如你所说,搜索符号很棘手):“应该使用<还是<=在 for 循环中”

(Yes, I happen to be able to find it easily as I've got a lot of upvotes on my answer...)

(是的,我碰巧能够轻松找到它,因为我的答案得到了很多赞......)

Basically, do whatever's most readable. The day someone correctly guesses that making a change away from the most readable form is going to solve a performance problem (without the help of a profiler) is the day I stop talking about performance :)

基本上,做任何最易读的事情。有人正确地猜测改变最易读的形式将解决性能问题(没有分析器的帮助)的那一天是我停止谈论性能的那一天:)

回答by Chris Jester-Young

Quite apart from the fact that any decent compiler does the right thing, and apart from that fact that in modern architectures there's no speed difference between >and >=comparisons, the bigger picture says that this is a "micro-optimisation" that doesn't affect runtime performance in the vast majority of cases.

除了任何体面的编译器都做正确的事情这一事实之外,除了在现代体系结构中没有速度差异>>=比较这一事实之外,更大的图景表明这是一种“微优化”,不会影响运行时绝大多数情况下的表现。

In the case of comparisons it usually doesn't affect readability whichever way you write it, but there are occasions when picking one boundary over the other is clearer: e.g.,

在比较的情况下,无论您以哪种方式编写它通常都不会影响可读性,但有时选择一个边界比另一个更清晰:例如,

##代码##

versus

相对

##代码##

I don't know about you, but I'd pick option 1 any day. :-) In cases that don't appreciably affect performance, such as this, the more readable option should win.

我不了解你,但我随时都会选择选项 1。:-) 在不会明显影响性能的情况下,例如这样,更具可读性的选项应该获胜。

回答by Gerald

That might have been true for some shady scripting languages that break down a >= into 2 comparisons, but whoever encouraged you to use that for C... well... you should probably try hard to forget everything they ever told you.

对于某些将 >= 分解为 2 个比较的阴暗脚本语言来说,这可能是正确的,但是无论谁鼓励您将其用于 C ……好吧……您可能应该努力忘记他们曾经告诉过您的一切。

回答by Ryan

This reminds me of the recommendation to use ++i instead of i++ (pre-increment vs. post-increment) because it was supposedlyone instruction faster. (I forget where I originally read about this, but it was probably C/C++ Users' Journal or Dr. Dobb's Journal but I can't seem to find a web reference.)

这让我想起了使用 ++i 而不是 i++(前增量与后增量)的建议,因为它被认为是更快的一条指令。(我忘记了我最初在哪里读到的,但它可能是 C/C++ 用户杂志或 Dobb 博士的杂志,但我似乎找不到网络参考。)

I seriously doubt that > or >= is faster or slower; instead write your code for clarity.

我严重怀疑 > 或 >= 更快或更慢;而是为了清晰起见编写代码。

As a side note, I developed a preference for the pre-increment (++i) operator even if the reason is now potentially outdated.

作为旁注,我对预增量 (++i) 运算符产生了偏好,即使原因现在可能已经过时。

回答by Scott Renz

For greater than zero, it must make two checks. It checks if the negative bit is off and it checks if the zero bit is off.

对于大于零,它必须进行两次检查。它检查负位是否关闭,并检查零位是否关闭。

For greater than or equal to zero, it only has to check if the negative bit is off, because we don't care if the zero bit is on or off.

对于大于或等于零,它只需要检查负位是否关闭,因为我们不关心零位是打开还是关闭。