4

Possible Duplicate:
How much faster is C++ than C#?

Hello!

Are there any cases in which C# is faster (has better performance) than C++ in practical use?

I heard that generic collections are a significant performance advantage over stl - is that true?

Has native code written in C# (unsafe block, pin pointers, Marshal...) the same performance as the same code written natively in C++?

Community
  • 1
  • 1
Przemysław Michalski
  • 9,627
  • 7
  • 31
  • 37
  • 3
    Duplicate of [How much faster is C++ than C#?](http://stackoverflow.com/questions/138361/how-much-faster-is-c-than-c)... See also: [C++ performance vs. Java/C#](http://stackoverflow.com/questions/145110/c-performance-vs-java-c). There are many other similar questions as well, but most tend to focus on specific algorithms or types of problems - if you have something specific in mind (say, insertion performance for `Collections.Generic.List` vs. `std::vector()`), then ask about that specifically. – Shog9 Oct 18 '10 at 17:06

4 Answers4

6

Are there any cases in which C# is faster (has better performance) than C++ in practical use?

and

Has native code written in C# (unsafe block, pin pointers, Marshal...) the same performance as the same code written natively in C++?

Yes, there are times when this can happen. See the answer here:

Why would I see ~20% speed increase using native code?

I heard that generic collections are a significant performance advantage over stl - is that true?

Not necessarily. STL can be incredibly efficient - often more so than generic collections in .NET.

However, in general, I wouldn't focus on performance at this level. C# and C++ are both "fast enough" if you develop in them correctly. You can make very, very performant code in either language - and just as easily, you can make code that performs horribly in either language.

Community
  • 1
  • 1
Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 4
    +1 for "just as easily, you can make code that performs horribly in either language" – Thorin Oct 18 '10 at 19:58
  • "STL can be incredibly efficient". That was never my experience. – J D Oct 19 '13 at 15:32
  • Use of STL iterators is slower than using an integer index in a List collection or a foreach.block in C#. – Dan Randolph Sep 10 '15 at 19:44
  • @DanRandolph Only if you compile without optimisations. With even low optimisations enabled on a modern compiler, C++ standard library iterators have *zero* overhead (in fact, they’re so transparent that compilers perform crazy transformations of the loop code, such as vectorisation). At best, all you can hope is that .NET matches their performance. It can’t possibly surpass them. – Konrad Rudolph Dec 06 '17 at 09:35
5

I heard that generic collections are a significant performance advantage over stl - is that true?

I highly doubt it, the STL uses templates, which gets around JIT overhead and still creates true, compiled, statically typed collections.

Has native code written in C# (unsafe block, pin pointers, Marshal...) the same performance as the same code written natively in C++?

Although C# unsafe code performs very well, it doesn't tie into the rest of the runtime very well... For example, try to do socket code with unsafe buffers, and you just end up using fixed blocks everywhere, and it turns into a nightmare. Not only that, C++ code will still perform better.

Are there any cases in which C# is faster (has better performance) than C++ in practical use?

Dynamic code is the biggest one that comes to mind, System.Reflection.Emit and Linq expressions (especially with the new features in C# 4.0) really make code generation in C# practical, whereas similar strategies in C++ might take significantly more effort (and therefore not be practical).

Shog9
  • 156,901
  • 35
  • 231
  • 235
LorenVS
  • 12,597
  • 10
  • 47
  • 54
  • 3
    It's conceivable that in a big app, STL could be slower, because it instantiates a zillion different versions of the template code, which could cause caching issues. I have no numbers to back up this theory, though! – Oliver Charlesworth Oct 18 '10 at 17:09
  • Very true, although I would assume most native compilers are very good at pulling out the sections of code that the various instantiations would have in common. – LorenVS Oct 18 '10 at 17:13
  • This is a rather subjective answer - I'd like to see some evidence for the claims (even if they "sound" feasible). – Jeff Yates Oct 18 '10 at 17:13
  • @Oli: one common scenario where some folks will experience performance problems with STL and won't with .NET collections is storing large objects. STL will copy them during insertion and resizing, while the managed collections merely store and copy references. Of course, you can use pointers in C++ and get the same advantage most of the time, so long as you're careful about giving *something* the responsibility of managing the memory. – Shog9 Oct 18 '10 at 17:14
  • Also, for any value types ( which are used all over the place in high performance C# ), the JIT generates completely different code when it instantiates a template with a specific type – LorenVS Oct 18 '10 at 17:15
  • FWIW: there was an implementation of STL for C++/CLR floating around for a while. Performance was *terrible* - while in straight C++ many of the operations get inlined, in managed code they do not... The combined overhead can be crushing. – Shog9 Oct 18 '10 at 17:20
2

I have had some performance improvement using C# instead of C++ for an application which was allocating/deallocating a lot of small sized objects, but with different sizes. I suspect garbage collection is a good tool for such jobs.

However, at least with C#/.NET 2.0, C++ yields definitely faster code for crunching number arrays (there is no SSE support for c# 2.0).

Alexandre C.
  • 55,948
  • 11
  • 128
  • 197
1

As far as I have understood .NET you are not able to write native code in C#. Even unsafe code is managed, it just has more access to system ressources and thus more responsiblity to clean up afterwards.

PVitt
  • 11,500
  • 5
  • 51
  • 85