Quick (Hopefully) C# Question

Really simply:

Does C# have the same temporary item creation performance issues that C++ does? If I have, say:

class Matrix()


&Matrix operator+(&Matrix1,&Matrix2)

M_total= M1 + M2 + M3 + M4 + M5;

I’ll get, what, 4 temporary object creations instead of the one that I’d get if I wrote a function to work as an accumulator.

I presume this limitation is still in place for C#?

(BTW, why are these things in place? Is it really that hard for a compiler to guess that if you have a string of binary operations that yield out a type, T, that it might just be most efficient to create that end type, T, and then do all the necessary operations internally in place?)

(Excuse any syntax errors, they’re mine; I don’t do this type of stuff much, but I know the basic problems - which is why I don’t do this stuff much.)

C# and the JIT compiler don’t usually optimize away any temporary objects, so yes, they’re all created and abandoned, one by one, as the binary additions are performed.

The good news is that it doesn’t matter because creating (not too big) objects that don’t survive the first garbage collector generation is blazingly fast. The first adjustment you have to make when moving from C++ to C#: don’t bother with sophisticated algorithms that avoid object creation. Just create your temporary objects and throw them away! It’s fast, it’s fun, it’s the .NET way!

Again, I do heavy numeric work. I’m willing to take some performance hit for ease of implementation. But it’s continually my impression that what other people refer to as “blazingly fast” and what I think of are vastly different.

I take it the object creation is faster because the GC that happens means there’s not a need to search for free memory when creating the temporary objects?

On an important, yet somewhat unrelated, note: Are there any C# compilers that work reliably under Linux? Also, are there C# MPI implementations?

(Yes, I know I’m weird for trying to do numerical stuff in C#. But the prospect of complete binary portability and OO is appealing.)

mono supposedly works quite well for the basic language and simpler runtime pieces. Livejournal uses it for their load-balancing frontend, if I remember correctly. The main missing pieces are mostly in the Windows-specific GUI libraries.

mouselock, I’ve read that C# takes nearly a 30% straight up speed hit when crunching numbers. You may want to look in to that before doing heavy numbers work.

I’m trying, but it’s not really easy to find reliable info.

Edit: For example, if I go here

C# seems to perform horribly on large matrices. However, the implementation they use to do the C# calculation “natively” is using a poor choice for array representation. (It’s in their best interest to make it appear as bad as possible, since they’re selling plugin replacements for the operations they’re talking about.)

I suspect it’s similar to trying to optimize operator overloaded performance in C++, where it’s doable but you have to be more aware of what’s going on under the hood. I suspect this is a generic tradeoff when trying to obtain good performance in syntactically easier languages.

The question will probably come down to whether it’s preferable to have:

Matrix A,B;




double A(3,3), B(3,3)


do i=1,3
  do j=1,3

Being able to not spend 2 weeks in implementing something when I change the operations I do may be worth taking an extra week per run when running it. Ultimately, it’s a lot cheaper to buy more/faster processing power than it is to somehow buy more time in the day for my direct interaction.

I believe where I originally read it was MS newsgroups. You may want to try swinging by there and asking about performance metrics.

Just a nitpick but C# has no references/pointers.

Note you can delegate any amount of your application to C interop for critical areas. It’s way easy.

C# doesn’t have flexible references like C/C++ (actually it does if you’re willing to box it into an unsafe block), but you can pass variables to methods as references to avoid create/copy overhead. I’m not sure what matrix implementation mouselock was working with but I know the ones Microsoft uses in Managed DirectX and XNA are pretty horrible because they don’t pass anything by reference, everything is by value which requires a fuckton of object creation and copying that isn’t really needed.

Seconded. Calling into C/C++ using either PInvoke style interop or by creating lightweight managed C++ wrappers over the native C/C++ code is ridiculously simple if you’re using .NET2.0/Visual Studio 2005 or higher. Quite a nice difference from the horror that is JNI.

Unfortunately I think at that point I might as well just write the thing in C. 85% of the work done is “critical” for that type of stuff, and while a light frosting of OO on top would be nice, if I’m going to have to deal with different compiling, differing modules, and tying the thing to a specific platform anyway, might as well just fall back to pure C.

I would say use C++, since you can fall back to as much raw C as you would please but can also use as much of C++ as you please.

But what the hell do I know. :)

For a numerical program you should use C/C++. The compilers optimize this kind of code way better – C# and JIT do very little optimization compared to current C++ compilers.

Object creation in C# basically means moving an internal heap pointer. No allocation calls are made to the operating system. Garbage collection is fast, too, if you take care that not too many objects die in “middle age”. Either let them expire quickly or let them persist for a long time.

Matrix calculations would be done using reference types, not value types, if you expect your matrices to reach any substantial size at all. This way you at least aren’t copying function parameters all the time. When chaining operators as in your example you’d still create a new temporary matrix on each return, though. It may be smarter to not use operator overloading at all (doesn’t work with generics anyway) but instead use regular methods with an output parameter.

My main concern with C++ is that I have to be super-careful to set up things properly now so that if someone else extends the code later they can’t grind it to a halt due to not being aware of the performance hits with temporary item instanciation. If I’m going to have everything end up as:

A = MultMatrix(B,C)

Then there’s no reason to even consider an OO language and I’ll just go back to pure C.

It seems like efficiency and ease of implementation are prety orthogonal (at least in this particular subfield where performance differences of 20% or less can be critical). I suppose that’s not too surprising.