为什么在比较两个可空值是否相等时不使用短路逻辑运算符 'and'？

Question

我有一个方法可以比较两个可为空的整数并将比较结果打印到控制台：

static void TestMethod(int? i1, int? i2)
{
    Console.WriteLine(i1 == i2);
}

这是它的反编译结果：

private static void TestMethod(int? i1, int? i2)
{
    int? nullable = i1;
    int? nullable2 = i2;
    Console.WriteLine((nullable.GetValueOrDefault() == nullable2.GetValueOrDefault()) & (nullable.HasValue == nullable2.HasValue));
}

结果或多或少符合我的预期，但我想知道为什么使用逻辑 'and' 运算符 (&) 的非短路版本而不是短路版本 (&&)。在我看来，后者会更有效率——如果已知比较的一侧是错误的，那么就没有必要评估另一侧。 & 运算符在这里是必需的还是这只是一个不够重要的实现细节？

Answer 1

如果您查看已编译的 CIL 代码 (Roslyn 2.0)，您实际上可以看到（第 IL_0016 行）对 Console.WriteLine() 调用进行短路的 br.s 指令如果 GetValue() 方法的结果不相等 (IL_0013)。我猜是你的 反编译器 不关心将其正确显示为 &&.

IL_0000:  nop
IL_0001:  ldarg.0
IL_0002:  stloc.0
IL_0003:  ldarg.1
IL_0004:  stloc.1
IL_0005:  ldloca.s   V_0
IL_0007:  call       instance !0 valuetype [mscorlib]System.Nullable`1<int32>::GetValueOrDefault()
IL_000c:  ldloca.s   V_1
IL_000e:  call       instance !0 valuetype [mscorlib]System.Nullable`1<int32>::GetValueOrDefault()
IL_0013:  beq.s      IL_0018

IL_0015:  ldc.i4.0
IL_0016:  br.s       IL_0028

IL_0018:  ldloca.s   V_0
IL_001a:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue()
IL_001f:  ldloca.s   V_1
IL_0021:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue()
IL_0026:  ceq
IL_0028:  call       void [mscorlib]System.Console::WriteLine(bool)
IL_002d:  nop
IL_002e:  ret

Answer 2

The result is more less what I expected but I wonder why non-short-circuit version of logical and operator (&) is used instead of short-circuit version (&&). It seems to me that the latter would be more efficient - if one side of comparison is already known then there is no need to evaluate the other side. Is there a reason that mandates usage of & operator or this is just implementation detail that is not important enough to bother?

这是一个很好的问题。

首先，我为 Roslyn 之前的可空降低代码和 Roslyn 中的原始实现开发了代码生成器。这是一些棘手的代码，有很多错误和错过优化的机会。我写了一系列关于 Roslyn 可空降低优化器如何工作的博客文章，文章从这里开始：

https://ericlippert.com/2012/12/20/nullable-micro-optimizations-part-one/

如果您对这个主题感兴趣，那么本系列文章可能会有很大帮助。第三部分特别重要，因为它讨论了一个相关问题：对于可空算术，我们是生成 (x.HasValue & y.HasValue) ? new int?(x.Value + y.Value) : new int?() 还是使用 && 或使用 GetValueOrDefault 还是什么？（答案当然是我尝试了所有这些并选择了最快的最小代码。）然而，该系列没有考虑您在这里的具体问题，即关于可为空的平等。可为 null 的相等性与普通提升算术的规则略有不同。

当然，我从2012年开始就没有在微软工作过，他们可能从那以后就换了；我不知道。（更新：查看上面评论中的链接问题，我似乎在 2011 年的原始实施中错过了优化，并在 2017 年修复了这一问题。）

回答您的具体问题：&& 的问题是当在右侧完成工作时，它 比 & 贵 运算符的 比 test-and-branch 便宜 。测试和分支不仅仅是更多的指令。显然，它是一个分支，具有很多连锁反应。在处理器层面，分支需要进行分支预测，而分支是可以预测错误的。分支意味着更多的基本块，记住，jit 优化器 运行s 在运行 time，这意味着 jit 优化器必须 fast 。允许说 "too many basic blocks in this method, I'm going to skip some optimizations"，因此可能不必要地添加更多基本块是一件坏事。

长话短说，如果右侧没有副作用，C# 编译器将生成 "and" 操作，编译器认为计算 left & right 会比计算更快更短评估 left ? right : false。通常，评估 right 的成本非常便宜，以至于分支的成本 比仅进行急切算术更昂贵 。

您可以在可空优化器以外的区域看到这一点；例如，如果您有

bool x = X();
bool y = Y();
bool z = x && y;

然后将生成为 z = x & y 因为编译器知道没有要保存的昂贵操作； Y() 已经 被调用。

为什么在比较两个可空值是否相等时不使用短路逻辑运算符 'and'？

Why is the short-circuit logical 'and' operator not used when comparing two nullables for equality?

c#

nullable