any language using a virtual machine (.net, mono, java etc) is always going to be slower than native code (C, C++).

This isn't true, by the way. In .NET, the first time you run a method it is compiled to native code and replaced in what amounts to the v-table. Any additional calls to that method will be native. So accessing "code" is nearly identical for managed as it is for native.

In addition, memory allocation in C++ is significantly slower than in C#. This is because the C++ allocator must traverse the designated user-mode address space looking for an available chunk of memory that's large enough to fit the size of memory you're trying to allocate. The longer your application runs, the more fragmented memory becomes and potentially the more difficult this will be, especially if you're leaking memory. With that said, a lot of people write their own allocator for C++ applications.

In C#, all memory is compressed and the next available block of memory is always pointed to by a reference. So allocating memory in C# is constant time, and almost instantaneous. With that said, attempting to allocate memory beyond the current generational cap does invoke a garbage collection, which can cause intermittent issues. But, proper memory management, allocating small bits at a time, etc... can cause the generations to change size over time and can result in very fast garbage collections.

Finally, when you compile your C++ code to machine language, the compiler is unable to make a large number of optimizations because it knows nothing about the machine your application will be running on. So it has to accept the "lowest common denominator" with respect to advanced CPU features. In contrast, when a .NET application is JIT compiled, it is compiled on the user's machine. Because of this, JIT compiled code can be significantly faster than code compiled natively on a dev's machine.

While it's true the .NET CLR still needs to leverage some of those available optimizations, which it likely does with VS 2012, it is untrue that a VM will always be slower than native code.

Oh, and on a related note, SharpDX generates binding assemblies from the DirectX headers/libraries without using C++/CLI wrappers. As a result, it's known to be significantly faster than SlimDX. It's also compatible with Windows 8 Metro Apps.

It clearly shows that c++ is faster in the most of cases.

If you pay special attention to the actual code being used, you'll see that he's intentionally using the slowest parts of C#, vs. the fastest parts of C++, even writing his own HashTable class when the C++ STL version is too slow for him. He's also not doing any dynamic memory allocation as part of his tests, which happens to be the part where C# shines. The end result is his tests are too narrowly defined to simulate any real application, and his choice of implementation suggests a specific goal of proving that C# is slower. I wouldn't view this as a legitimate benchmark.

C++ is very fast when used by a computer-science expert, who's aware of pointer-aliasing, cache-line-aliasing, pre-caching, data layout trade-offs, balancing algorithmic complexity with hardware realities, etc...

When used by a beginner, C++ is not only slow, but also very dangerous -- with programs seeming to work properly, but actually leaking resources and corrupting their own memory, causing bugs that a beginner has no chance of finding.

C# is much friendlier to beginners, and it's "performance penalties" aren't really that bad when you're not capable of writing expertly performant C++ code anyway.


Your talent as a computer scientist has a much bigger impact on performance than whether you're using native vs JIT/managed binaries.

Also, N.B. the tools that C++ gives you to generate blindingly fast code also do exist in modern revisions of C# (e.g. fixed memory, explicit data layouts, raw pointers, unsafe native code), it's just that they're generally not used by default because they lead to the same issues that make C++ a dangerous language.

When you say beginner, looks like you talking about a beginner programmer, but to me, and correct me if Im wrong, you can master C#/java/whatever, but the only way to became a "no beginner" in C++, is programming in C++... do you agree with this sentence?
I mean, c# and java will teach you OOP much faster than C++ in my opinion, but the only way to learn the stuff that makes C++ powerfull(the ones you mention as being computer-science expert skills), is coding on C++.. Since other languages abstract out all of that stuff..

As I mentioned above, C# has actually added lots of the 'dangerous' C++ features, like raw pointers, and low-level performance tuning features, like explicit data layouts. So if you "fully master" every possibly usage of C#, then those skills will all transfer over to C++.
However, yes, C++ has lots of quirks of it's own that you still have to learn, like the rule of three, and it has it's own idioms such as RAII, which doesn't appear in many other languages.
So if you're comfortable with your computer-science and computer-architecture knowledge (which is theory that doesn't depend on any language) and you've mastered some other languages, you will find C++ much easier to learn than a complete beginner, but nonetheless you will still have plenty of new material to learn.

When I started programming in C# in the beginning of this year I realized how ridiculous hard C++ is, ive been programming only in C++ since I started to learn programming, the difference in productivity is scary.[/quote]Indeed, they don't call it a "productivity language" for nothing.
So, if you're a beginner programmer, it would be wise to start with a language that lets you focus on programming, rather than also having to focus on language-specific quirks and difficulties (which C++ has plenty of).