6

I am developing a tool that will be used for reading, processing and displaying data. I am confused about my choice between C++/C#. I have done C++ console programming only. No GUI or no C#.

I will be using VS2010 (compulsory).

I did a lot of reading on the web. I understand that when it comes to high performance, C++ is the best choice. I will list what I need:

  1. A GUI
  2. Reading files (one file is about 25 MB and a total of about 5000 images might be used at a time for further processing)
  3. Processing the data. Mathematical operations mainly.
  4. Display the data. These may be heavy data again. (~GBs). I am thinking of using OpenGL for this.

I started of with Windows Form Application under VC++. I made a GUI and it was rather quick. I had some issues in reading files. Most people around me are using MFC (dialog based). But they mainly work on firmware programming. They recommended I should develop in MFC. But I realized my productivity decreased.

Now its up to me what to use. So my questions is: For the tasks this tool supposed to perform, is it worth going to MFC or its better I move to C# (or C++ CLR). Time is not the biggest concern if I gain significant improvement in terms of performance.

This is the first part of development. Later, it needs to be expanded. Keeping that in mind, what is better for future prospects. (we might need to use CUDA for processing, if this information is useful.)

I hope I am clear. Kindly be gentle and ask further details, if needed.

EDITS:

Thanks for a clear responses. The data being read are binary images (25 MB~ -35 MB~ each). 1000s of images are stacked and processed (not all at once, but pixel by pixel). I have implemented it in MATLAB so I have a fair idea about the process. Mainly, statistical analysis and Fourier analysis will be done on the data. Finally a point cloud is generated. I am thinking of using a PCL (point cloud library which is in C++). These are not very big, since I am displaying in MATLAb right now. In future, files might get bigger so we are moving to C++/C# environment. Displayed data needs to have functionality such as selecting points, and displaying option to show properties/plots of that particular point etc. Graphics are not heavy to display, but more important is the ability to select a feature.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
Naresh
  • 633
  • 1
  • 7
  • 26
  • 1
    "Time is not the biggest concern if I gain significant improvement in terms of performance." Then do a prototype in each language, measure the time for the critical operations and choose the fastest one. – Daniel Daranas Apr 16 '13 at 09:45
  • 2
    You can always mix the two - use C# for ease of GUI design and code a native C++ or (better) C++/CLI module for the tasks that are not fast enough in C#. Beware of premature optimisation though - best to get something working and then see if it's too slow. – Roger Rowland Apr 16 '13 at 09:45
  • 4
    you can use C# and there is no problem but i suggest that you use WPF – gasroot Apr 16 '13 at 09:47
  • well, we are using MATLAB now, and even that is fast enough for us. I am not sure how MATLAB performance compares to C++/C#. – Naresh Apr 16 '13 at 09:47
  • 1
    The *processing the data* part is the only part that might really benefit from C++, but without knowing what sort of processing it's impossible to say if you would need to go to native code to make it fast enough... The graphical display can be done in managed code using GDI+ or XNA if it needs to be really fast. Personally, I avoid C++ where possible because it is so much slower to develop in. – Matthew Watson Apr 16 '13 at 09:48
  • well. The processed data is point clout and it will be pretty big. I can do some optimizations. I got pretty fast machine with high end gfx. – Naresh Apr 16 '13 at 09:54
  • 2
    Firstly before giving advice we need more information on what it is you are doing. What is this data? Why do you think you should use OpenGL to display it. Having only ever used C++ console applications there is a huge learning curve to OpenGL. I suggest that MFC is a very outdated technology and I would not use this for any new project. Speed-wise MFC is certainly not any faster than C#. For reading files doing some maths on the data, displaying it on screen there should be no real difference between C# and C++ but your own mileage may vary (I don't know what it is you are doing!) – TheKingDave Apr 16 '13 at 09:57
  • My tool will process data that comes out of our indigenous sensors. These are raw binary files (images). Each of about 25 MB. We create a large stack (10000s of images) and then these images are processed. OpenGL was recommended to view the data, not a requirement again. I need to check options here too. – Naresh Apr 16 '13 at 10:07
  • *"They recommended I should develop in MFC."* - By all means don't listen to them. *"But I realized my productivity decreased."* - And that is a natural conclusion when using *MFC*. *"is it worth going to MFC"* - That's never worth it. Still *MFC* is not the only option for GUI/OS functionality in C++ and there are excellent alternatives (well, not really alternatives when *MFC* is obsolete in the first place), like *Qt*. Still this doesn't answer your question in any way, but I'm not sure it can be answered that easily. – Christian Rau Apr 16 '13 at 10:33
  • I started of with Qt, but it didn't match what I wanted. Further, we all use VS2010 and we want to keep it consistent. I quit Qt because of this: http://stackoverflow.com/questions/15897146/qt-binary-reading-error-in-qdatastream – Naresh Apr 16 '13 at 10:40
  • @Naresh If such a small inconvenience made you quit *Qt*, then you won't have much fun with *MFC* either. – Christian Rau Apr 16 '13 at 10:44
  • It was not the only reason. I liked Qt. It was simple and quick. But colleague/supervisor wanted VS2010 so I moved. Right now, I mainly testing what is better for us. Qt is *not* off the table. – Naresh Apr 16 '13 at 10:48

1 Answers1

7

C# and C++ will give almost similar performance unless you are talking of massive amount of data over long period of time. In most case, C++ could give you a few fraction of second over C#; so it's not really a great advantages in any daily application.

However, in cases where ultimate performance is absolutely critical, such as drivers or video games, the milliseconds gained and the manual memory control offered by C++ is an obvious advantage. For everything else, C# is generally easier and faster to write and debug. The managed code means you don't, most of the time, have to handle any memory allocation or deallocation. It is also my opinion that it gives much "cleaner" code file.

GUI in .NET is done in WinForms or WPF. Most would probably point you towards WPF as the obvious choice because it is a much... younger technology where one of the main advantage is being drawn over DirectX, which mean high end computer will draw interface much faster.

However, if you plan in displaying lot of custom information in, let's say 3D, you might find it much easier to code directly you request to DirectX/OpenGL. You can then use a wrapper such as SlimDX to make your life easier. But you should know that if you never handled this kind of code before, learning to code anything in DirectX or OpenGL oriented is really not an easy task. The shaders alone is a very special world.

If you can provide more complete information about the data being handle and the way you plan in displaying it, we can point you towards a more complete solution.

UPDATE:

My guess, in this case, is you won't find much difference in performance between C# and C++, even more if you are using a outside library for some of the computation. Both C# and C++ can use the same libraries. If the graphic computations were that heavy, most likely the best approach would be to transfer them to the GPU over DirectX/OpenGL, but that would only be if you think of having minutes or even hours of intensive computation. So it might be easier and faster to use C#.

LightStriker
  • 19,738
  • 3
  • 23
  • 27
  • 2
    *However, in cases where ultimate performance is absolutely critical, such as drivers ... the milliseconds gained and the manual memory control offered by C++ is an obvious advantage.* [And non-obvious disadvantages from the lack of control of memory usage](http://msdn.microsoft.com/en-us/library/windows/hardware/gg487420.aspx#EFE). – ta.speot.is Apr 16 '13 at 10:07
  • @ta.speot.is: Interesting. Is it also valid for C? Because to my knowledge most driver would be written in C and not C++ as from what I understand drivers don't have any vtable, which defeat the polymorphism offered by C++... – LightStriker Apr 16 '13 at 10:16
  • question updated. Thanks. – Naresh Apr 16 '13 at 10:21
  • 2
    FYI, C++ and C# are only similar when you haven't started aggressive optimizations. C++ always has quite a lot of room for making things faster (finer control over memory, SIMD, etc., much better optimizing compilers and flags, etc.), but C# does so much less... – user541686 Apr 16 '13 at 10:23
  • 1
    @Mehrdad: C++ will have a clear advantage only if you are deploying your executable on a very known and defined CPU, allowing you to flag the compiler for that CPU execution set. However, C# can do those optimization at run time, giving you close, but not quite, the same performance over all CPU without having to know on what platform you're deploying. It is why in video games, particularly on gaming console, are always in C++. The devs know the console and can optimize greatly for it. But in a day to day application on standard computer, the gain vs pain in the ass factor might not worth it. – LightStriker Apr 16 '13 at 10:31
  • 1
    @LightStiker True that JIT did bring C# close to C++ in terms of average performance, but with C# you are paying a heavy tax for safety. For example in C# each and every access to an object is checked if the "pointer" is still valid, this costs performance. In C++ it is in your hand to check and thus you have a handle of safety vs. speed. In C++ you have just way more options than C#. – rioki Apr 16 '13 at 11:49
  • one last thought .. will it be very complicated to combine unmanaged C++ code into managed C++/C#? – Naresh Apr 16 '13 at 13:48
  • @LightStriker: "C# can do those optimization at run time"... this is a fairy tale everyone loves to tell. It certainly *could* be true, but as far as I've ever seen, it isn't. The JIT doesn't optimize code nearly as well as a C++ compiler. – user541686 Apr 16 '13 at 16:06
  • @rioki Define an implementation for *each and every access to an object is checked if the "pointer" is still valid*. Noting that in C# it's very hard to get an invalid pointer, except for `null`. One implementation would be to say that `null` is represented internally as a sentinel object whose every method implementation is `throw new NullReferenceException()`. The cost of invoking those methods is the same as invoking any other object's methods. – ta.speot.is Apr 17 '13 at 03:33
  • @ta.speot.is Remember, in C# the garbage collector is a generational one, not mark and sweep. As a result your objects may be collected, if you let them lie around for long enough. It is a bit more complicated. Nevertheless, in C++ I can not check the validity at all or only once in a method. It is not that much, but C# security features are there and they are slowing down execution. C++ is a language that can vastly outperform C#, calming otherwise is missing the point of C#; then again it very seldom matters. In most cases I know the performance is lost in architectural errors. – rioki Apr 18 '13 at 08:11
  • @rioki You missed the point. Checking objects aren't `null` is slow, so never make an object `null`. Make it a special sentinel object whose job is to throw `NullReferenceException`s for every method. When you compare for `null`, compare for the sentinel object. The CLR can make an exception during garbage collection, not to collect the sentinel objects. [Or just not collect objects in general](http://msdn.microsoft.com/en-AU/library/system.gc.keepalive.aspx). And [the Microsoft GC uses both generational and mark-and-sweep](http://msdn.microsoft.com/en-au/library/ee787088.aspx) algorithms. – ta.speot.is Apr 18 '13 at 08:19
  • @rioki And to be clear, I'm not saying that you as a programmer should make the sentinel object. The CLR VM **can** do this behind the scenes. Making checking for valid objects ... just as fast as not checking for them. [The actual implementation is to do something like this, it doesn't check every object access](http://stackoverflow.com/questions/11239410/what-is-the-clr-implementation-behind-raising-generating-a-null-reference-except). – ta.speot.is Apr 18 '13 at 08:21
  • @ta.speot.is ... and you are missing my point and the point of C#. C# was designed to be "safe". To ensure this safety the runtime has to jump through some extra hoops. Getting it to go fast is only a secondary goal. With C++ or rather C it is the total opposite, it was designed to be fast and will not prevent you from shooting yourself in the foot. Nevertheless writing really fast C++ is very hard, but in C# the language and runtime will not let you. Here is [handy chart](http://reverseblade.blogspot.de/2009/02/c-versus-c-versus-java-performance.html), the question is does it really matter? – rioki Apr 18 '13 at 08:53
  • @rioki I'm not saying C++ is not faster. It is. But C# is not slower for the reasons you describe. Complaining that "each and every access to an object is checked if the "pointer" is still valid" when the pointer is *not* checked and that the garbage collection is "not mark and sweep" when it does implement a mark-and-sweep mechanism is just bizarre. – ta.speot.is Apr 18 '13 at 08:57
  • @ta.speot.is [What Happens During a Garbage Collection](http://msdn.microsoft.com/en-us/library/ee787088.aspx#what_happens_during_a_garbage_collection) Yes, mark, no sweep. Generations, yes. Different algorithm. Any questions? – rioki Apr 18 '13 at 09:08
  • @rioki Someone should tell Stephen Toub: "[if the .NET Framework garbage collector instead worked on a reference counting scheme rather than *the mark-and-sweep scheme it does use*, this cycle could be a problem](http://msdn.microsoft.com/en-us/magazine/cc163324.aspx)". It's generational AND mark-and-sweep. And regardless, it's an implementation detail. They might tune it. – ta.speot.is Apr 18 '13 at 10:38