C#/.net efficiency

[msnews.microsoft.com]

Two simple questions:
1) Shouldn't the code snippets below produce the same IL?
2) Which will be faster?

TIA!

// Bit shift method
return (19 * (y >> 4)) + (x >> 4) + 1;

IL:
{
// Code size 13 (0xd)
.maxstack 8
IL_0000: ldc.i4.s 19
IL_0002: ldarg.2
IL_0003: ldc.i4.4
IL_0004: shr
IL_0005: mul
IL_0006: ldarg.1
IL_0007: ldc.i4.4
IL_0008: shr
IL_0009: add
IL_000a: ldc.i4.1
IL_000b: add
IL_000c: ret
}

// Mathematical equivalent
return (19 * (y /16) + (x / 16) + 1);

IL:
{
// Code size 20 (0x14)
.maxstack 3
.locals init ([0] int32 CS$1$0000)
IL_0000: nop
IL_0001: ldc.i4.s 19
IL_0003: ldarg.2
IL_0004: ldc.i4.s 16
IL_0006: div
IL_0007: mul
IL_0008: ldarg.1
IL_0009: ldc.i4.s 16
IL_000b: div
IL_000c: add
IL_000d: ldc.i4.1
IL_000e: add
IL_000f: stloc.0
IL_0010: br.s IL_0012
IL_0012: ldloc.0
IL_0013: ret
}

 

[Jon Skeet [C# MVP]]

Two simple questions:
1) Shouldn't the code snippets below produce the same IL?

No - they might give different results if x or y are negative, for one
thing.

2) Which will be faster?

I'd expect the shift to be faster, but the obvious course of action is
to try it. However, unless this code is in the bottleneck of your app,
the chances are very slim that it'll make any significant difference.
Write it in the form you find most readable.

 

[msnews.microsoft.com]

Thanks for the response. I hadn't considered negative values for x/y only
because that should never be the case in my app. It does makes sense though
when you consider that they could be negative. As far as speed goes, I also
expect the bit shift to be a tiny bit faster...but as you said, it shouldn't
really be enough to matter.

Thanks!

now I'm off to figure out where to change my usename in OE

 

[Stefan Simek]

Thanks for the response. I hadn't considered negative values for x/y only
because that should never be the case in my app. It does makes sense though
when you consider that they could be negative. As far as speed goes, I also
expect the bit shift to be a tiny bit faster...but as you said, it shouldn't
really be enough to matter.

Thanks!

now I'm off to figure out where to change my usename in OE

No - they might give different results if x or y are negative, for one
thing.



I'd expect the shift to be faster, but the obvious course of action is
to try it. However, unless this code is in the bottleneck of your app,
the chances are very slim that it'll make any significant difference.
Write it in the form you find most readable.

I'd just like to add - the difference is not in the division itself, but
in the compensation for the shift of negative numbers Jon mentioned.

This is the output of the JIT:

Shift version: Divide version:

00000000 push ebp 00000000 push ebp
00000001 mov ebp,esp 00000001 mov ebp,esp
00000003 sub esp,8 00000003 sub esp,8
00000006 push edi 00000006 push edi
00000007 push esi 00000007 push esi
00000008 mov edi,ecx 00000008 mov edi,ecx
0000000a mov esi,edx 0000000a mov esi,edx
0000000c mov eax,esi 0000000c mov ecx,esi
0000000e test ecx,ecx
00000010 jns 00000015
00000012 add ecx,0Fh
0000000e sar eax,4 00000015 sar ecx,4
00000011 imul eax,eax,13h 00000018 imul ecx,ecx,13h
00000014 mov edx,edi 0000001b mov eax,edi
0000001d test eax,eax
0000001f jns 00000024
00000021 add eax,0Fh
00000016 sar edx,4 00000024 sar eax,4
00000019 lea eax,[eax+edx+1] 00000027 lea eax,[ecx+eax+1]
0000001d pop esi 0000002b pop esi
0000001e pop edi 0000002c pop edi
0000001f mov esp,ebp 0000002d mov esp,ebp
00000021 pop ebp 0000002f pop ebp
00000022 ret 00000030 ret


Once you change the parameters to uint, the compiled funcitons become
almost equal, except for register usage, which should not affect
performance on todays processors

HTH,
Stefan