Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>would anybody know a good article/reference explaining how .NET sockets use I/O completion ports under the hood?</p> </blockquote> <p>I suspect the only reference would be the implementation (ie. Reflector or other assembly de-compiler). With that you will find that <em>all</em> asynchronous IO goes through an IO Completion Port with call backs being processed in the IO-thread pool (which is separate to the normal thread pool).</p> <blockquote> <p>use 5 completion ports</p> </blockquote> <p>I would expect to use a single completion port processing all the IO into a single pool of threads with one thread per pool servicing completions (assuming you are doing any other IO, including disk, asynchronously as well).</p> <p>Multiple completion ports would make sense if you have some form of prioritisation going on.</p> <blockquote> <p>My question is this: should I expect the same performance using C++ sockets and C# sockets?</p> </blockquote> <p>Yes or no, depending on how narrowly you define the "using ... sockets" part. In terms of the operations from the start of the asynchronous operation until the completion is posted to the completion port I would expect no significant difference (all the processing is in the Win32 API or Windows kernel).</p> <p>However the safety that the .NET runtime provides will add some overhead. Eg. buffer lengths will be checked, delegates validated etc. If the limit on the application is CPU then this is likely to make a difference, and at the extreme a small difference can easily add up.</p> <p>Also the .NET version will occasionally pause for GC (.NET 4.5 does asynchronous collection, so this will get better in the future). There are techniques to minimise garbage accumulating (eg. reuse objects rather than creating them, make use of structures while avoiding boxing).</p> <p>In the end, if the C++ version works and is meeting your performance needs, why port?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload