Sockets

07/31/2011 17:57 ImFlamedCOD#16
Mr. Pop don't rule out the notion of using unsafe code in c#. It has purpose's. I do agree with you tho. In c# unless you understand it fully keep away from using unsafe code.
07/31/2011 19:16 _DreadNought_#17
ImFlamedCOD, Long time no see.

Nice to see your face back once and a while. Hi, I'm dreadnought!
08/01/2011 03:28 ImmuneOne#18
Quote:
Originally Posted by Mr_PoP View Post
unsafe code it's too messy in c#, and if you are using it because you think you're getting better performance ,in reality, while it might be better, it's not noticeably better, it's a hell of a lot worse to maintain though.

and don't use memcpy on managed memory :P , anyways it's seems OK but try to avoid any unsafe code in you're C# source :)
You have no idea what you're talking about :rolleyes:
08/01/2011 06:10 Mr_PoP#19
Quote:
Originally Posted by ImFlamedCOD View Post
Mr. Pop don't rule out the notion of using unsafe code in c#. It has purpose's. I do agree with you tho. In c# unless you understand it fully keep away from using unsafe code.
Agreed :)

Quote:
Originally Posted by ImmuneOne View Post
You have no idea what you're talking about :rolleyes:
i really do! but the question why do you use unsafe while you can use the C# built in functions?

like instead of 'memcpy ' use Buffer.BlockCopy ?
08/01/2011 09:47 Korvacs#20
Quote:
Originally Posted by Mr_PoP View Post
Agreed :)

i really do! but the question why do you use unsafe while you can use the C# built in functions?

like instead of 'memcpy ' use Buffer.BlockCopy ?
Unsafe code is the most efficient way to access/modify data in memory, anyone who denies this is in denial about it.

You just need to run some simple tests, copying 100k objects from 1 array to another using memcpy, and the same test using BlockCopy.
08/01/2011 17:13 ImmuneOne#21
Quote:
Originally Posted by Mr_PoP View Post
Agreed :)



i really do! but the question why do you use unsafe while you can use the C# built in functions?

like instead of 'memcpy ' use Buffer.BlockCopy ?
You run the tests, compare them and then tell me why you should use memcy or Buffer.Blockcopy instead.
08/01/2011 21:14 BaussHacker#22
Quote:
Originally Posted by ImmuneOne View Post
You run the tests, compare them and then tell me why you should use memcy or Buffer.Blockcopy instead.
memcpy is native, which makes the performance better as it's probably c or c++. Right?
08/01/2011 22:06 teroareboss1#23
or use..

Code:
  void MEMCPY(byte[] Received, byte[] Buffer, int Len)
        {
           // fixed (byte* pointer = Received, buffer = Buffer)
           //     MSVCRT.MEMCPY(pointer, buffer, Len);
            byte[] Received = new byte[Len];
            for (int x = 0; x < Len; x++)
            {
                Received[x] = Buffer[x];
            }
        }
08/02/2011 00:02 CptSky#24
Managed vs Unmanaged in C#... I know these things, but it will give a better idea of the reality and you'll see that the difference is so little that you can use what you want...

Tested on Windows XP x64, for a copy of 50'000'000 elements and tested 1000 times for precision. All values in ms.
TargetBuffer.BlockCopyArray.Copymemcpy (void*)memcpy (IntPtr)memcpy (void*, fixed byte*)memcpy (fixed byte*, fixed byte*)
x6431.54730.73430.20130.92234.81729.760
x8643.60641.20837.30937.62640.05137.704
Any28.42227.09725.85826.54230.53126.087

Results:
Allocating managed resources takes more times than unmanaged resources.
Byte[] = new Byte[], Byte* = (Byte*)Marshal.AllocHGlobal()

x64 is fastest than x86 on 64 bits OS.

Any CPU is fastest than x64 on 64 bits OS and probably on 32 bits OS (x86).

Array.Copy is fastest than Buffer.BlockCopy.

There is no difference between void* and IntPtr.

There is no difference between fixed pointer and pointer.

Native function memcpy is fastest than Array.Copy.
08/06/2011 23:24 GRASSHOPPA#25
I don't see a need to change what anyone is comfortable with because it would be fractions of a nanosecond faster
Hopefully I'm not the only one that sees it that way

Nice release bauss..might save it for later
08/07/2011 00:53 BaussHacker#26
Quote:
Originally Posted by GRASSHOPPA View Post
I don't see a need to change what anyone is comfortable with because it would be fractions of a nanosecond faster
Hopefully I'm not the only one that sees it that way

Nice release bauss..might save it for later
I changed some few things, if you want to see what, feel free to check out my source ^^

Working on some extremely sockets atm.
08/08/2011 13:44 Korvacs#27
Quote:
Originally Posted by GRASSHOPPA View Post
I don't see a need to change what anyone is comfortable with because it would be fractions of a nanosecond faster
Hopefully I'm not the only one that sees it that way

Nice release bauss..might save it for later
Sadly its not fractions of a nanosecond faster, its several milliseconds faster, and when writing a server several milliseconds is a long time.
08/09/2011 00:33 GRASSHOPPA#28
Quote:
Originally Posted by CptSky
Tested on Windows XP x64, for a copy of 50'000'000 elements and tested 1000 times for precision. All values in ms.
Correct me if I'm wrong but isn't he saying each function was called 50 million times?
I try to keep things as efficient as possible(I of course don't know as much as a majority of the people reading this)..but I don't see anything I'd design that calls anything hundreds of millions of times
08/09/2011 00:37 _DreadNought_#29
lolz.

He means an array with 50million shit in
Easy to make
Code:
ulong[] x = new ulong[50000000];
for (ulong i = 0; i < 50000000; i++)
{
x[i] = i*3/4;
}
then just copying the array to another array and seeing how long it takes.

What he meant was each function was called One Thousand times.

^^All for testing.
08/09/2011 01:17 GRASSHOPPA#30
ohhhh...that makes a bit more sense lol
Either way ill stick to Array.copy