Quote:Original post by gharen2
I can confirm that math code that's optimized with unsafe code is much faster.

Quote:Original post by krum

Quote:Original post by capn_midnight
The performance hit from using unsafe code is HUGE.

I'm pretty sure that this isn't correct. I've spent a substantial amount of time researching this subject, and I've found that there is no performance penalty for unsafe code per se in C#.

There is a very slight penalty to using the 'fixed' keyword which is often associated with unsafe because the runtime pins the array, but even that usually isn't bad unless used in an inner loop (normally you'd use 'fixed' outside of a loop).

Quote:
Just to prove my point, take the following code:

*** Source Snippet Removed ***

Now, lets take a look the machine code that test1() generates

*** Source Snippet Removed ***

and test2()

*** Source Snippet Removed ***

Clearly, using the unsafe pointer is faster, because there is no null reference check - which is obvious as the first three instructions of test2().

There is a penalty to using the 'fixed' keyword, which includes a null reference check and the pointer is pinned, but clearly if you were going to iterate over all of the elements in the array using the unsafe pointer would be substantially faster.

	class Program {		static void Main(string[] args) {			int[] numbers = new int[1024];			Random r = new Random();			for(int i = 0; i < numbers.Length; ++i) {				numbers = r.Next();			}			AddOneSafe(numbers);			unsafe { fixed(int* p = numbers) {				AddOneUnsafe(p, numbers.Length);			}}			Console.ReadKey();		}		static void AddOneSafe(int[] array) {			for (int i = 0; i < array.Length; ++i) {				++array;			}		}		static unsafe void AddOneUnsafe(int* array, int length) {			for (int i = 0; i < length; ++i) {				++array;			}		}	}

!u 00152ff0Normal JIT generated codeConsoleApplication1.Program.AddOneSafe(Int32[])Begin 00220128, size 1a00220128 56               push        esi00220129 33D2             xor         edx,edx0022012B 8B7104           mov         esi,dword ptr [ecx+4]0022012E 85F6             test        esi,esi00220130 7E0E             jle         0022014000220132 8D449108         lea         eax,[ecx+edx*4+8]00220136 830001           add         dword ptr [eax],100220139 83C201           add         edx,10022013C 3BF2             cmp         esi,edx0022013E 7FF2             jg          0022013200220140 5E               pop         esi00220141 C3               ret!u 00152ff8Normal JIT generated codeConsoleApplication1.Program.AddOneUnsafe(Int32*, Int32)Begin 00220158, size 1c00220158 57               push        edi00220159 56               push        esi0022015A 8BF9             mov         edi,ecx0022015C 8BF2             mov         esi,edx0022015E 33C9             xor         ecx,ecx00220160 85F6             test        esi,esi00220162 7E0D             jle         0022017100220164 8D148F           lea         edx,[edi+ecx*4]00220167 830201           add         dword ptr [edx],10022016A 83C101           add         ecx,10022016D 3BCE             cmp         ecx,esi0022016F 7CF3             jl          0022016400220171 5E               pop         esi00220172 5F               pop         edi00220173 C3               ret

Quote:Original post by RipTorn

Quote:Original post by Fiddler
For large arrays you should not copy elements around. In this case, if you do not want to resort to unsafe code, use the following snippet:

            GCHandle h0 = GCHandle.Alloc(array, GCHandleType.Pinned);            try            {                // h0.AddrOfPinnedObject() will get you your IntPtr            }            finally            {                h0.Free();            }

Awesome. Where/how did you find/figure this out? [smile]

This is by far the best way, and safe provided you don't buffer overrun I guess

Quote:Original post by krum
With all due respect, Washu, this has nothing to do with unsafe code - rather this is a good demonstration of how poor the JIT's optimizer is. Either way, I think we'll find that the safe code may take at least one additional clock cycle per loop due to the additional add

Quote:

lea         eax,[ecx+edx*4+8]

vs

lea         edx,[edi+ecx*4]

I believe the fact that the unsafe code has a few more instructions to set the function up is largely insignificant. Even if the CPU can do both LEA instructions in the same number of clock cycles, I think to suggest that in this case unsafe code produces a substantial performance penalty is going overboard.

Quote:The more extreme case would be if you had an array of 4x4 transformation matrices, say from an animation, that you needed to multiply with a parent transform. Using safe code could be tremendously slower because it would need to copy each matrix at least twice for each operation, whereas using pointers could reduce the memory bandwidth requirements.

My point is that using unsafe code per se is not slower. What you do with it is - like anything - a whole different story.

Quote:Original post by Niksan2
Another one for Washu I guess, as per my earlier post on the method I use, mainly because I have to expose a byte* to an unmanaged dll (the only time I use pointers, and maybe that's what the OP wanted it for), for the unsafe bandwagoners :D, the question being I currently do it like so.

fixed (byte *_bp = byteArray)
{
somethingorother(_bp);
}

Can this be changed to an attribute as part of the invoked prototype so it can auto marshal the array to a pointer ? I was reading http://blogs.msdn.com/ericgu/archive/2004/07/13/181897.aspx and they mentioned some possible change, although this was an idea for whidby so much use for me, as mentioned in that thread, when you're dealing with multiple paramaters it can yield some fugly code (doing it as I do now).

Cheers.