What factors should I consider when choosing between C# and C++ for an image-processing project?

Question

I want to develop some image processing code and I am wondering if there is a big difference between developing them in C++ and C#?

Is there any detail document that explains what is good to implement in C# and what is good to implement in C++?

As far as I know, since C# code are compiled to machine code just before running (using .NET CLR JIT compiler), there should not be a lot of difference between the two language if during code development, you look how the specific language suggest to implement a design patterns (For example, using a lot of new versus of using a fixed arrays).

Edit: There are some other parameters that I did not think at first but I am looking at the now when I read some of the answers: 1- It is a high level projects which means that I can ask the user to have a very good computer (A lot of memory and multi-core processors) 2- I can assume that user has a very good graphic card, so I may be able to use its GPU for processing. 3- I think WPF is good for this development (Am I right!). Is there any similar library for C++? I worked with MFC, but I am not sure that MFC is as good as WPF when working on projects that needs to show images and the GUI is very important.

Answer 1

.NET IL is compiled to machine code, just as C++. But almost always the C++ code will be faster, because:

• The compilation time becomes part of the runtime (once only, but sometimes this is an issue)
• JIT-compilers spend less time on optimization than AOT-compilers, for the reason mentioned above. Therefore the code generated by a JIT is generally slower. For instance, JITs usually do not vectorize anything, which is important for image-processing. Most often, it isn't even possible to generate vectorized code due to VM restrictions (Mono.Simd is an exception)
• Languages in a VM have to ensure that the program does not escape the VM. For instance, they have to check array bounds on every access (unless the compiler can prove that the index is always in range; keep in mind that JIT compilers do not spend much time on such analyses).
• For time-critical kernels you can insert assembler-instructions by yourself. VMs don't allow this because the assembler may break out of the VM.

In some cases managed code can be faster than unmanaged code:

• A garbarge collector allows memory to be allocated more efficiently than malloc. But, unless the memory just used for a short time, however Mark-And-Sweep also needs some time.
• A JIT may compile code with more static assumptions on the code (like, it knows all possible implementations of a virtual function) and redo the compilations when the assumption does not hold anymore. This is done in Java HotSpot, but not in Microsoft's JIT nor Mono.

Summary: If execution speed is important, use C++. But C# can be fast enough, as Paint.NET shows. Also consider the option to code mostly in C# and once you are not satisfied with the speed of some important function, reimplement it in C++/CIL or call your optimized function using P/Invoke.

Answer 2

As someone who has converted an image processing library from C++ to C#, and done the benchmarks the language has little influence on the speed of what you are doing, more important are the algorithms you are using and which api's you are using to manipulate the images (i.e. in windows use lockbits on the bitmap). I managed to gain significant speed increases due to the fact that is possible for me to write more parallel code a lot easier in C# than in C++ and the ability to not be stuck with just Monitor.Wait (I'll admit I am not a C++ threading expert, in fact I am not a C++ threading amateur) but having a wide variety of options to easily parallelize operations (which in graphics are pretty intrinsic) made for massive speed increases when converting from C++ to C# (plus only having to worry about freeing up resources and not memory made life a lot easier too). Obviously if you are very comfortable in C++, then you can write faster code in C++, but you know C++ and SIMD quite well to beat C# compiler. I should also note that we converted from C++ to C# assuming that we would lose about 10% speed, and the reason we converted was the cost in time of adding new features was so high that a rewrite to C# became worth our while, the end product ending up being faster was just a bonus (now also I should mention that the original library was written before SIMD extension where added to Visual C++, so using it was no available to the original library author).