Sockets

[ImFlamedCOD]

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.

[_DreadNought_]

ImFlamedCOD, Long time no see.

Nice to see your face back once and a while. Hi, I'm dreadnought!

[ImmuneOne]

Originally Posted by Mr_PoP

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

[Mr_PoP]

Originally Posted by ImFlamedCOD

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

Originally Posted by ImmuneOne

You have no idea what you're talking about

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 ?

[Korvacs]

Originally Posted by Mr_PoP

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.

[ImmuneOne]

Originally Posted by Mr_PoP

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.

[BaussHacker]

Originally Posted by ImmuneOne

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?

[teroareboss1]

or use..

  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];
            }
        }

[CptSky]

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.

Target	Buffer.BlockCopy	Array.Copy	memcpy (void*)	memcpy (IntPtr)	memcpy (void*, fixed byte*)	memcpy (fixed byte*, fixed byte*)
x64	31.547	30.734	30.201	30.922	34.817	29.760
x86	43.606	41.208	37.309	37.626	40.051	37.704
Any	28.422	27.097	25.858	26.542	30.531	26.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.

[GRASSHOPPA]

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

[BaussHacker]

Originally Posted by GRASSHOPPA

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.

[Korvacs]

Originally Posted by GRASSHOPPA

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.

[GRASSHOPPA]

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

[_DreadNought_]

lolz.

He means an array with 50million **** in
Easy to make

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.

[GRASSHOPPA]

ohhhh...that makes a bit more sense lol
Either way ill stick to Array.copy