C# vs C++ performance

[VectraMan]

I found this:

Performance: C# vs C++ « Systematic Gaming

This bloke reckons he gets 10 times the performance out of C++ than C# on a simple sort of increasing sized arrays, which seemed unlikely. So I tried his code, and for me it came out more like 3 times the performance from C++.

However, he'd used an unsafe fixed struct, which others on that site had said kills the performance, and sure enough when I replaced it with a regular class the C# version was about twice as fast as C++. Bugger.

But there's a fairly obvious difference in that the C++ version is making lots of extra copies, so I fixed it using rValue references (exactly what it's meant to solve). And phew, the C++ version is 2-3 times faster than C#.

I also changed his version to include the memory allocation and deallocation in the timing, which I thought was a fairer real world test. This means that C++ has one extra step in that it does the deallocation, whereas GC in C# means it sort of maybe does the deallocation next Tuesday. But I think that's fair as that's how things are done.

The other difference is that C++ can allocate an array of objects, but C# has to allocate an array and then new each member of the array, so that's a whole extra step and a whole load of extra newing. But that's what C# makes you do.

Other than that it comes down to std::sort vs. Array.Sort<T> which presumably are well optimised.

C# results:
1024    0.935831229946823,
2048    1.35896461701138,
4096    3.01492927173705,
8192    7.40412538465084,
16384   26.1312610960332,
32768   67.3828796676673,
65536   150.520059113658,
131072  339.230656410242,
262144  807.599520330098,
524288  1974.64114852586,

C++
    1024        0.668617
    2048        1.92414
    4096        2.63548
    8192        6.49269
   16384        12.9487
   32768        26.5373
   65536        56.3965
  131072        115.083
  262144        238.201
  524288        483.761
(values are milliseconds)

Interesting n'est-ce pas? Hardly a comprehensive test, but I can't see where the performance advantage is coming from unless it is the .NET runtime / JIT compiler / GC being less efficient. And that's pretty fundamental.

I'll post the code if anybody cares. Maybe somebody with more C# experience than me can do a better job.

[AtW]

I had some proper tests - C# was very close to C++, that means using pointers in C# when necessary.

If your bottleneck is memory allocation then you should avoid doing it in the first place - it's not a test of languages per se, but memory sub systems.

HTH

[Scotgal]

I have been down the road of comparing programming languages performance (above assembly) and although C will win on pure speed the time for development and other bottlenecks make the performance gains insignificant. That is of course for normal application, systems and realtime programs are a different matter, you don't want the garbage collector kicking in at a critical moment.

[doodab]

Interesting n'est-ce pas? Hardly a comprehensive test, but I can't see where the performance advantage is coming from unless it is the .NET runtime / JIT compiler / GC being less efficient. And that's pretty fundamental.

I'll post the code if anybody cares. Maybe somebody with more C# experience than me can do a better job.

It would be interesting to see how the C++ code fares in C++ .NET

[AtW]

It would be interesting to see how the C++ code fares in C++ .NET

Well made point.

[d000hg]

It's difficult to benchmark exactly because as you've seen, porting the same code simply doesn't work. You'd have to give the algorithm to experts in each language and even then it's down to who knows their tools.

Interesting though.

[doodab]

I had a look at the code (I am not a C# expert by any means though), the purpose seems to be to sort contiguous blocks of memory so I'm not sure that using the a class in C# achieves what is desired as although the classes might get moved around the data[] is I think allocated elsewhere and will not be moved at all. It might make more sense to use a struct containing several fields if what is desired is a block of 130 bytes. Maybe this says something about the difference in thought process required.

Interestingly his original post (here) was about avoiding sorting large structures like this because it's a fairly stupid thing to do.

I would guess some of the measured difference can be accounted for by array bounds checking and numerical result checking that the CLR will be doing, the allocation probably makes a difference as well. It would be interesting to see how it panned out if you factored in a lot of small allocations & actually putting real data in there as that would be a lot more realistic use case IMO. I know I've never had cause to sort 128mb of zeroed memory.

[VectraMan]

It would be interesting to see how the C++ code fares in C++ .NET

That depends on what you mean. With C++ .NET you can do "pure" CLR, which means all .NET, and I would imagine that'd be much the same as C# because it's doing the same thing. Or you can do mixed CLR with native code, so assuming you do the faster sort with native code it'll be much the same as the regular C++ performance.

No doubt someone will say that proves it's not the language, but the platform, but a) C++ .NET isn't C++, and b) of course it's the platform, but as you can't seperate C# from .NET that's the only thing you can test.

[VectraMan]

It's difficult to benchmark exactly because as you've seen, porting the same code simply doesn't work. You'd have to give the algorithm to experts in each language and even then it's down to who knows their tools.

It's using the built in, designed by experts std::sort, and the built in, designed by experts Array.Sort<T>. I can't imagine either is an ineffficient search algorithm, in fact I'd be very suprised if they weren't identical.

[VectraMan]

I had a look at the code (I am not a C# expert by any means though), the purpose seems to be to sort contiguous blocks of memory so I'm not sure that using the a class in C# achieves what is desired as although the classes might get moved around the data[] is I think allocated elsewhere and will not be moved at all.

The default behaviour of C# is to store a reference to the objects, which means the sort can swap two items around by swapping the references only. Whereas C++ the swap works directly on the objects, so how he had it every swap was two copies of the data in the class. I guess that's typical C++, and that was the case where C++ was half the speed. But I changed it to use a dynamically allocated buffer and rValue references to do a faster move.

Which maybe shows that an average C# programmer following typical practices probably produces faster code than an average C++ programmer doing the same, but a good C++ programmer will spot the inneficiency and can produce faster code than is possible in C#.