Does using unchecked context hurt performance or portability in C#?

Question

I want to implement a fast hash function that will use int datatype and rely on integer overflow. MSDN says that in order to guarantee that overflows don't trigger exceptions I have to use unchecked blocks for that code.

Suppose I surround only that computation in an unchecked block. Will my code have any performance or portability problems because of that?

@ Marc Gravell: Yes, I known that, but there's a chance that my code is reused in a project with `checked` enforced and I want my code to work right. — sharptooth, Oct 20 '11 at 08:34
@ Marc Gravell: Actually what bothers me is - will I still have all the nice perks of MSIL+JIT combination if I use `unchecked`? — sharptooth, Oct 20 '11 at 08:35
you are right to *add* `unchecked` for that; the point I was trying to make is that it will behave exactly like it did before - yes you get the same MSIL+JIT behaviour. Indeed, this helps *guarantee* that you get what you want. As has been noted, it is theoretically possible that some CPU (maybe on micro-framework somewhere) has to do *more* work in the case of `checked`, but that is a: unlikely to be a problem, and b: doesn't really impact your `unchecked` stuff - and it is entirely an implementation detail. — Marc Gravell, Oct 20 '11 at 08:39
sharptooth, it sounds like you are confusing `unchecked` with `unsafe`. Using `unchecked` is still safe and has very little impact. — H H, Oct 20 '11 at 08:45

score 10 · Answer 1 · answered Mar 10 '16 at 08:06

checked add only one process instruction:

checked
{
    int y = x * x;
05297978  mov         eax,dword ptr [ebp-10h]  
0529797B  imul        eax,dword ptr [ebp-10h]  
0529797F  jno         05297986  //if not overflow: goto 05297986
05297981  call        72A29522  //invoke exception
05297986  mov         dword ptr [ebp-14h],eax  
}

unchecked
{
    int yy = xx * xx;
0529799E  mov         eax,dword ptr [ebp-18h]  
052979A1  imul        eax,dword ptr [ebp-18h]  
052979A5  mov         dword ptr [ebp-1Ch],eax  
}

xanatos · Accepted Answer · 2011-10-31T12:52:02.410

Technically only the checked blocks should slow. So I don't think an unchecked block (a block where the framework has to do less checks) could slow. It isn't a context switch or something similar. The JIT simply doesn't emit instructions to check for overflow/underflow. Now, clearly if someone created a "special" processor where overflow must be simulated and ported Mono on it, or where an overflow causes different results than on Intel processors, an unchecked block would be slower (because the JIT would have to "simulate" it). But note that the base types of .NET are defined in the ECMA standard. Signed ints must be based on two-complement for example, and their size must be 8, 16, 32, 64 bits. There isn't much space for "strange" processors that use 36 bits integers.

score 8 · Answer 3 · answered Oct 20 '11 at 11:52

As a rule you can expect unchecked arithmetic to be slightly faster, but it's pretty much never worth asking the opposite question to yours (viz. "will using checked hurt my performance?").

Checked and unchecked just mean there are slightly different rules as to how operators like +, *, and - are treated, and you should use the one appropriate for the case in hand.

In this case, you quite definitely want unchecked, so you should state this in your code. This actually increases portability, since you will then have the same behaviour whatever compiler switches are used with it.

sll · Answer 4 · 2011-10-20T08:34:51.223

I've created two methods, one wrapped by checked and an other by unchecked. By looking into IL only one difference is mul operation (which does multiplication operation), for checked mul.ovf is generated and for unchecked - mul.

To summarize, I believe difference in a single CPU operation does not make any impact on performance, the only one difference would be in case of overflow using checked - in this case OverflowException will be generated which obviously slow down execution.

MSDN:

The following Microsoft intermediate language (MSIL) instructions throw an OverflowException:

mul.ovf.

...

[Test]
public void Checked()
{
    checked
    {
        int i = int.MaxValue;
        i = i * 100;
        Debug.WriteLine(i);
    }
}

[Test]
public void UnChecked()
{
    unchecked
    {
        int i = int.MaxValue;
        i = i * 100;
        Debug.WriteLine(i);
    }            
}

And then using ILDASM see IL:

CHECKED():

// Code size       27 (0x1b)
  .maxstack  2
  .locals init ([0] int32 i)
  IL_0000:  nop
  IL_0001:  nop
  IL_0002:  ldc.i4     0x7fffffff
  IL_0007:  stloc.0
  IL_0008:  ldloc.0
  IL_0009:  ldc.i4.s   100
  **IL_000b:  mul.ovf** !!!
  IL_000c:  stloc.0
  IL_000d:  ldloc.0
  IL_000e:  box        [mscorlib]System.Int32
  IL_0013:  call       void [System]System.Diagnostics.Debug::WriteLine ...

UNCHECKED():

  // Code size       27 (0x1b)
  .maxstack  2
  .locals init ([0] int32 i)
  IL_0000:  nop
  IL_0001:  nop
  IL_0002:  ldc.i4     0x7fffffff
  IL_0007:  stloc.0
  IL_0008:  ldloc.0
  IL_0009:  ldc.i4.s   100
  **IL_000b:  mul** !!!
  IL_000c:  stloc.0
  IL_000d:  ldloc.0
  IL_000e:  box        [mscorlib]System.Int32
  IL_0013:  call       void [System]System.Diagnostics.Debug::WriteLine(...)

I would call shenanigans on the decompile. Look at the IL instead - this is usually just a subtle difference in the opcode. Also, using `byte` in one and `int` in the other is confusing the matter. If I use the `Int32` code for both, the **only** difference is `add` vs `add.ovf` — Marc Gravell, Oct 20 '11 at 08:18
@Marc Gravell♦: yep I just changed this to be more relevant, thanks for nte anyway! — sll, Oct 20 '11 at 08:26
I believe we need a more deep description for both mul/mul.ovf regarding how them generated to CPU instructions and only then we can compare. But in general I believe this show that difference is very small, single instruction per single operation is not too much — sll, Oct 20 '11 at 08:58

Does using unchecked context hurt performance or portability in C#?

4 Answers4