通过强制转换为uint而不是检查负值来执行范围检查是否更有效？

我在.NET的List源代码中偶然发现了这段代码：

// Following trick can reduce the range check by one
if ((uint) index >= (uint)_size) {
  ThrowHelper.ThrowArgumentOutOfRangeException();
}

显然，这比（？）更有效 if (index < 0 || index >= _size)

我对这招背后的理由感到好奇。一条分支指令真的比两次转换贵uint吗？还是正在进行其他优化，以使此代码比其他数字比较快？

为了解决房间里的大象问题：是的，这是微优化，不，我不打算在代码中到处使用它–我只是很好奇；）

在MS Partition I的12.1节（支持的数据类型）中：

有符号整数类型（int8，int16，int32，int64和本机int）及其对应的无符号整数类型（无符号int8，无符号int16，无符号int32，无符号int64和本机无符号int）的区别仅在于整数的位如何不同被解释。对于将无符号整数与有符号整数区别对待的那些操作（例如，比较或带溢出的算术运算），有单独的指令将整数视为无符号（例如cgt.un和add.ovf.un）。

也就是说，从a到a的转换仅是簿记事项-从现在开始，堆栈/寄存器中的值现在被认为是无符号的int而不是int。intuint

因此，一旦将代码JITted，两次转换应该是“免费的”，然后可以执行无符号比较操作。

假设我们有：

public void TestIndex1(int index)
{
  if(index < 0 || index >= _size)
    ThrowHelper.ThrowArgumentOutOfRangeException();
}
public void TestIndex2(int index)
{
  if((uint)index >= (uint)_size)
    ThrowHelper.ThrowArgumentOutOfRangeException();
}

让我们编译这些代码并查看ILSpy：

.method public hidebysig 
    instance void TestIndex1 (
        int32 index
    ) cil managed 
{
    IL_0000: ldarg.1
    IL_0001: ldc.i4.0
    IL_0002: blt.s IL_000d
    IL_0004: ldarg.1
    IL_0005: ldarg.0
    IL_0006: ldfld int32 TempTest.TestClass::_size
    IL_000b: bge.s IL_0012
    IL_000d: call void TempTest.ThrowHelper::ThrowArgumentOutOfRangeException()
    IL_0012: ret
}

.method public hidebysig 
    instance void TestIndex2 (
        int32 index
    ) cil managed 
{
    IL_0000: ldarg.1
    IL_0001: ldarg.0
    IL_0002: ldfld int32 TempTest.TestClass::_size
    IL_0007: blt.un.s IL_000e
    IL_0009: call void TempTest.ThrowHelper::ThrowArgumentOutOfRangeException()
    IL_000e: ret
}

不难看出，第二个代码更少，分支更少。

真的，根本没有强制转换，可以选择使用blt.s和bge.s还是使用blt.s.un，其中后者将传递的整数视为无符号，而前者将它们视为有符号。

（注意对于那些不熟悉CIL，因为这是与CIL答案一个C＃问题，bge.s，blt.s和blt.s.un是“短”的版本bge，blt和blt.un分别blt离开本层两个值和分支如果第一小于所述第二时blt.un当将它们视为无符号值时，将它们视为有符号值，同时弹出堆栈的两个值并分支（如果第一个小于第二个值，则分支）。

完全是微型选择，但有时候值得做。进一步考虑，与方法主体中的其余代码一起，这可能意味着某些内容是否落在抖动限制（是否为内联）之内，并且如果他们不愿意使用帮助程序抛出超出范围的异常，则它们是可能会尝试尽可能确保内联，并且额外的4个字节可能会有所不同。

确实，内联差异很有可能比减少一个分支机构要大得多。没有很多时间竭尽全力确保进行内联值得，但是一类如此大量使用的核心方法List<T>肯定会是其中之一。

请注意，如果您的项目checked不是，则此技巧将无效unchecked。最好的情况是它会变慢（因为每个强制转换都需要检查是否溢出）（或至少不是更快），最坏的情况是OverflowException如果您尝试通过-1作为index（而不是您的例外），您将得到一个。

如果您想“正确”地编写它，并且以一种“一定会起作用”的方式写，则应在

unchecked
{
    // test
}

各地的测试。

假设_size是一个整数，它是列表的私有数据，并且index是此函数的参数，需要对其有效性进行测试。

进一步假设该_size值始终> = 0。

然后，原始测试将是：

if(index < 0 || index > size) throw exception

该优化的版本

if((uint)index > (uint)_size) throw exception

具有一个比较（如前一个示例中的两个比较。）由于强制转换只是重新解释了这些位并使>实际上是一个无符号的比较，因此不使用其他CPU周期。

为什么行得通？

只要索引> = 0，结果就是简单/简单的。

如果index <0，(uint)index它将变成一个很大的数字：

示例：0xFFFF的int值为-1，而uint的值为65535，因此

(uint)-1 > (uint)x 

如果x是肯定的，则始终为真。

是的，这样更有效。范围检查数组访问时，JIT会执行相同的技巧。

转换和推理如下：

i >= 0 && i < array.Length变(uint)i < (uint)array.Length，因为array.Length <= int.MaxValue使array.Length具有相同的值(uint)array.Length。如果i碰巧是负数(uint)i > int.MaxValue，则检查失败。

显然，在现实生活中并没有更快。检查此：https : //dotnetfiddle.net/lZKHmn

事实证明，由于英特尔的分支预测和并行执行，更明显，更易读的代码实际上可以更快地运行...

这是代码：

using System;
using System.Diagnostics;

public class Program
{


    const int MAX_ITERATIONS = 10000000;
    const int MAX_SIZE = 1000;


    public static void Main()
    {

            var timer = new Stopwatch();


            Random rand = new Random();
            long InRange = 0;
            long OutOfRange = 0;

            timer.Start();
            for ( int i = 0; i < MAX_ITERATIONS; i++ ) {
                var x = rand.Next( MAX_SIZE * 2 ) - MAX_SIZE;
                if ( x < 0 || x > MAX_SIZE ) {
                    OutOfRange++;
                } else {
                    InRange++;
                }
            }
            timer.Stop();

            Console.WriteLine( "Comparision 1: " + InRange + "/" + OutOfRange + ", elapsed: " + timer.ElapsedMilliseconds + "ms" );


            rand = new Random();
            InRange = 0;
            OutOfRange = 0;

            timer.Reset();
            timer.Start();
            for ( int i = 0; i < MAX_ITERATIONS; i++ ) {
                var x = rand.Next( MAX_SIZE * 2 ) - MAX_SIZE;
                if ( (uint) x > (uint) MAX_SIZE ) {
                    OutOfRange++;
                } else {
                    InRange++;
                }
            }
            timer.Stop();

            Console.WriteLine( "Comparision 2: " + InRange + "/" + OutOfRange + ", elapsed: " + timer.ElapsedMilliseconds + "ms" );

    }
}

在英特尔处理器上进行探索时，我发现执行时间没有差异，可能是由于多个整数执行单元所致。

但是，当在既没有分支预测又没有整数执行单元的16MHZ实时微处理器上执行此操作时，则存在显着差异。

一百万次较慢的代码迭代耗时1761毫秒

int slower(char *a, long i)
{
  if (i < 0 || i >= 10)
    return 0;

  return a[i];
}

100万次迭代速度更快的代码花费了1635毫秒

int faster(char *a, long i)
{
  if ((unsigned int)i >= 10)
    return 0;
  return a[i];
}