Dude, you really seem to have zero clue about compiler improvements and C# library improvements in particular. C# can well compete in millisecond space, where I agree with you is when we talk microseconds!!!
However, I do want to add that regardless of the compiler, even if every *milli* second of *latency* is important, that windows (and hence C#) is NOT the way to go. Its top precision is around 15 ms and the OS is not real time at all (your code might easily be executed way later than 15 ms due to all kinds of stuff windows has scheduled before your code)
not accurate, you can get down to 1ms precision on windows boxes. There was some article with code some time ago on msdn about a highresolution timer which explained the matter quite eloquently.
Yeah, the HPET, but even though the timer itself is accurate, windows is NOT and hence the result is not. Still waiting on your answer though why my previous remark would be a 'ridiculous blanket statement'
also not accurate, well relatively speaking. You still are subject to latency between the measurement and the reporting but you are subject to the exact same latency in a Unix machine (speaking about Windows 1ms timer precision). Blanket statement because even a library in C++ may add a lot more functionality than you may use (that is the nature of libraries unless you code every last bit of functionality yourself and just the bare minimum which I bet you even do not do, do not tell me you do not use any C++ libraries ;-). The uncalled functions do not add any baggage whatsoever in terms of latency or throughput. Honestly you dont think saying "This means it is NOT code that is tailored to your specific needs. With C++ you can nail it down and only use code you really want." sounds like the analysis of a 13 year old? I think this is plenty enough for me, I agree with you that with top coders in place, ample resources, top hardware that you get more out of C++ in microsecond time space than what C# can deliver but everywhere else I claim C# is very much up to the competition. I guess the biggest performance difference I have seen was between C++ AMP vs C# TPL which was respectable and clearly made C++ shine in that regards.
Windows might schedule some interrupt handling between the hardware call and the report, which might add up to a lot of milliseconds. The thing is, that if you want to program directly to the TCP/IP layer for example, there will always be .NET libraries between that layer and your code, which will slow things down. No, it's exactly what's happening. These .NET libraries are enormous and contain tons of code that is well meant but won't help you in most specific situations and hence will slow you down.
a) same on a Unix box you have latency between the call and report. Period. b) I run more messages per second over tcp in my C# app to another box than any other software, commercial or open source that I tried so far. c) Libraries too big? How big? How big is too big? How enormous? tons of code? How many tons? You still resort to blanket statements. I do not want to argue with someone who really is just stubborn. There are array collection classes in .Net that are as fast as array operations in C++. No matter what a top coder in C++ you are. I am getting really tired of this, sorry, and bail out of this. I am not into pissing contests. I made my case clear where C++ shines and you insist and continue to hate C#, I can live with that. Its an ignorant and somewhat intellectually limited attitude but hey, whatever works for you. Peace.
Uh, actually it is theoretically possible but for example if you were only to time simple code such as "a = a + b". There are ways to convert the CLI into native compiled code and have a look there. Some people have done it. In some cases the .Net functions will match the speed of C++. If you time only those specific cases C# will be as fast as C++, so it doesn't matter how much bloat you have for loading a host of .Net libraries into memory together with your executable, as they only occupy a bit of memory and thats the only downside. However in practice, for most normal usage cases, I agree that .Net will be slower for the reason you mentioned. It's simply not possible to have such ease of use within a framework such as .Net and at the same time have a lean and mean compiler. Verions 4, like he mentioned, improves on a lot of things though. Hehe if you guys spent more time on a general programming forum you would know not to enter into discussion on "C# vs C++" or any language for that matter. There's never a clear answer for all cases, only for specific cases.
I guess you have never heard about a realtime OS ? Take a look here for example: http://www.redhat.com/products/mrg/realtime/ Ok, you obviously didnt try some C++ compiled software then. Very fine by me. But if you still want to make your point, then just send me a VERY simple example of compiled C# code that does nothing but just send a basic network packet and I'll show you why it's slow.