c++/C# Performance Question
-
I'm in a new department that is currently using c++/VS2002. The lead programmer and myself are have a debate over what the performance differences are between c++ and C#. Googling, I can find only a few things and none of them give a really good comparison. My own feelings are that they are fairly similar overall, but I cannot find any proof. Can anyone point me where to look to find the info? Thanks in advance Tom
-
I'm in a new department that is currently using c++/VS2002. The lead programmer and myself are have a debate over what the performance differences are between c++ and C#. Googling, I can find only a few things and none of them give a really good comparison. My own feelings are that they are fairly similar overall, but I cannot find any proof. Can anyone point me where to look to find the info? Thanks in advance Tom
C++ is obviously going to be faster. The *real* question is, how much faster, could you tell the difference for the sort of apps you write, on the hardware it will be run on, and how much more does it cost in man hours to use C++ instead ?
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
C++ is obviously going to be faster. The *real* question is, how much faster, could you tell the difference for the sort of apps you write, on the hardware it will be run on, and how much more does it cost in man hours to use C++ instead ?
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
We are building some rather complex applications that all boil down to computational geometry on a complex collections of object. They are really extensions of 3d CAD systems into the manufacturing systems. We are currently moving from code embedded (think plugin) in CAD system to free standing applications. As a result we really have two issues. The first is a data/object management issue because our data structures become very complex. The text version of the data can be 200+k lines long. So for these routines, C#'s advantages of no pointers and no memory leaks (both big problems currently) will out way performance issues. The questions on performance have to do with parsing speed and dynamic memory management. Our lead programmer thinks that any system with memory garbage collection has to be too slow by definition and therefore not worth consideration. The second is a rendering/computationally issues. These will be fairly tightly defined routines where computational speed is an issue, although a difference of 10-20% probably would not be noticed. Especially as processor speeds increase. We are also going to be recoding these for multi-core support, so ease of threading here will be an issue. In terms of hardware, we are going to be supporting all versions from windows 2000 to vista, both 32 and 64 bit. So porting between these OSs will be a problem. I've seen an article on codeproject that goes over the coding differences between 32 and 64 bit in C++ and it looks like it will be a problem. I believe that .net does this automatically for us. And ultimately Linux, but no customers have requested it. If we limit ourselves to what MONO supports, I think this may be a solution. This is going to be a 6-8 person project for the next couple of years. We are probably looking at 500k lines of code. So overall programmer efficiency is going to be a really big deal. At a minimum I think that we need to move to VS Team, but am going to have to get more info before I can convince the others. Thanks for quick reply. Tom
-
We are building some rather complex applications that all boil down to computational geometry on a complex collections of object. They are really extensions of 3d CAD systems into the manufacturing systems. We are currently moving from code embedded (think plugin) in CAD system to free standing applications. As a result we really have two issues. The first is a data/object management issue because our data structures become very complex. The text version of the data can be 200+k lines long. So for these routines, C#'s advantages of no pointers and no memory leaks (both big problems currently) will out way performance issues. The questions on performance have to do with parsing speed and dynamic memory management. Our lead programmer thinks that any system with memory garbage collection has to be too slow by definition and therefore not worth consideration. The second is a rendering/computationally issues. These will be fairly tightly defined routines where computational speed is an issue, although a difference of 10-20% probably would not be noticed. Especially as processor speeds increase. We are also going to be recoding these for multi-core support, so ease of threading here will be an issue. In terms of hardware, we are going to be supporting all versions from windows 2000 to vista, both 32 and 64 bit. So porting between these OSs will be a problem. I've seen an article on codeproject that goes over the coding differences between 32 and 64 bit in C++ and it looks like it will be a problem. I believe that .net does this automatically for us. And ultimately Linux, but no customers have requested it. If we limit ourselves to what MONO supports, I think this may be a solution. This is going to be a 6-8 person project for the next couple of years. We are probably looking at 500k lines of code. So overall programmer efficiency is going to be a really big deal. At a minimum I think that we need to move to VS Team, but am going to have to get more info before I can convince the others. Thanks for quick reply. Tom
-
We are building some rather complex applications that all boil down to computational geometry on a complex collections of object. They are really extensions of 3d CAD systems into the manufacturing systems. We are currently moving from code embedded (think plugin) in CAD system to free standing applications. As a result we really have two issues. The first is a data/object management issue because our data structures become very complex. The text version of the data can be 200+k lines long. So for these routines, C#'s advantages of no pointers and no memory leaks (both big problems currently) will out way performance issues. The questions on performance have to do with parsing speed and dynamic memory management. Our lead programmer thinks that any system with memory garbage collection has to be too slow by definition and therefore not worth consideration. The second is a rendering/computationally issues. These will be fairly tightly defined routines where computational speed is an issue, although a difference of 10-20% probably would not be noticed. Especially as processor speeds increase. We are also going to be recoding these for multi-core support, so ease of threading here will be an issue. In terms of hardware, we are going to be supporting all versions from windows 2000 to vista, both 32 and 64 bit. So porting between these OSs will be a problem. I've seen an article on codeproject that goes over the coding differences between 32 and 64 bit in C++ and it looks like it will be a problem. I believe that .net does this automatically for us. And ultimately Linux, but no customers have requested it. If we limit ourselves to what MONO supports, I think this may be a solution. This is going to be a 6-8 person project for the next couple of years. We are probably looking at 500k lines of code. So overall programmer efficiency is going to be a really big deal. At a minimum I think that we need to move to VS Team, but am going to have to get more info before I can convince the others. Thanks for quick reply. Tom
Tom Thorp wrote:
no pointers and no memory leaks (both big problems currently)
Then perhaps moving to C# is a good thing. No well written C++ code will leak, at least not in ways that are 'big problems'. I worked on a 3D home design program in C++, and we didn't have any significant memory leaks. C# does require you to manage leaks, however, especially for graphics objects.
Tom Thorp wrote:
The questions on performance have to do with parsing speed and dynamic memory management. Our lead programmer thinks that any system with memory garbage collection has to be too slow by definition and therefore not worth consideration.
For a CAD system, I suspect he may be right. I have written image processing apps in C#, however, and they work just fine.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
C++ is obviously going to be faster. The *real* question is, how much faster, could you tell the difference for the sort of apps you write, on the hardware it will be run on, and how much more does it cost in man hours to use C++ instead ?
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
C++ is obviously going to be faster.
Not necessarily true, depends heavily on the implementer.
**
xacc.ide-0.2.0.75 - now with C# 3.5 support and Navigation Bar!
**
-
We are building some rather complex applications that all boil down to computational geometry on a complex collections of object. They are really extensions of 3d CAD systems into the manufacturing systems. We are currently moving from code embedded (think plugin) in CAD system to free standing applications. As a result we really have two issues. The first is a data/object management issue because our data structures become very complex. The text version of the data can be 200+k lines long. So for these routines, C#'s advantages of no pointers and no memory leaks (both big problems currently) will out way performance issues. The questions on performance have to do with parsing speed and dynamic memory management. Our lead programmer thinks that any system with memory garbage collection has to be too slow by definition and therefore not worth consideration. The second is a rendering/computationally issues. These will be fairly tightly defined routines where computational speed is an issue, although a difference of 10-20% probably would not be noticed. Especially as processor speeds increase. We are also going to be recoding these for multi-core support, so ease of threading here will be an issue. In terms of hardware, we are going to be supporting all versions from windows 2000 to vista, both 32 and 64 bit. So porting between these OSs will be a problem. I've seen an article on codeproject that goes over the coding differences between 32 and 64 bit in C++ and it looks like it will be a problem. I believe that .net does this automatically for us. And ultimately Linux, but no customers have requested it. If we limit ourselves to what MONO supports, I think this may be a solution. This is going to be a 6-8 person project for the next couple of years. We are probably looking at 500k lines of code. So overall programmer efficiency is going to be a really big deal. At a minimum I think that we need to move to VS Team, but am going to have to get more info before I can convince the others. Thanks for quick reply. Tom
Tom Thorp wrote:
If we limit ourselves to what MONO supports, I think this may be a solution.
Search for threads about in on the Lounge. MONO has some fairly large sized holes in the base classes. MONO also uses GTK.net for graphics instead of trying to port winforms (too win32 centric in design). Even if none of the former are a problem for you, if a *nix port is in your likely future you'd probably do better writing the UI with GTK.net now instead of having to rewrite it later.
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
-
I'm in a new department that is currently using c++/VS2002. The lead programmer and myself are have a debate over what the performance differences are between c++ and C#. Googling, I can find only a few things and none of them give a really good comparison. My own feelings are that they are fairly similar overall, but I cannot find any proof. Can anyone point me where to look to find the info? Thanks in advance Tom
Hi Tom, I understand your doubts; we had the same doubts more than ten years ago, when we considered switching embedded system programming to Java; Java has a similar garbage collection approach. But we did switch over, and soon we were glad we did because of the increased programmer efficiency and code robustness. The garbage collection concept is quite OK if you pay some attention to it. Of course you must (continue to) care about the number of objects you create; every object sooner or later must be retrieved to recycle the memory it was occupying. Switching an image processing application from C++ to C# should not be seen as an open invitation to turn every pixel into an object... Here are some examples that limit the object generation rate: 1. when performing complex string operations (say a number of concatenations), you will be better of using a StringBuilder. 2. short-lived objects, large or small, that only consume a limited number of CPU cycles in their life span, need special attention, to avoid the gc effort becoming noticeable. If you currently manage these objects yourself, you can continue to do this, by recycling them, rather than letting them fade away. I do not recommend you do this all the time, but when applied to a few classes at the heart of your application domain, it may prove quite useful. Of course these examples may seem like giving in on the advantages of C#, but that would be true only partially and locally. It is similar to general performance optimisation: in order to improve overall app performance, one must look for hot spots and then give in a bit to gain some (or a lot). Hope this may be helpful. :)
Luc Pattyn [My Articles] [Forum Guidelines]