C# and C++

[Blueychan]

C++ is cross-platform, and C# is Windows only. C# offer the power of C++ and the simplicity of VB, is that true? Is C# really as fast as C++?

 

[Crusty]

There are so many variables here that it's impossible to give you a straight up one is faster then the other. Although, in general Managed C# code will be slower then unmanaged C++ code. C# is certainly fast enough for application use, and I've even got some real time systems written in C# that perform very well. Would it be faster if I wrote it in C++, most likely.... but then again I'd probably still be coding it.

 

[Blueychan]

Crusty,

Do you know of good book on C# that you recommend?

 

[Markbnj]

I always get a chuckle out of claims that languages are "cross-platform." C++ isn't cross platform unless the program doesn't do anything except maybe read stdin and write text to stdout or a file. I'm sure that's an oversimplification, but the bottom line is that any non-trivial program written in C++ to run on, say, Linux is not going to port right over to Windows.

C# on the other hand is certainly windows-specific, but it is damn near java with the broken parts fixed. All depends on how you want to look at it.

Is C# really as fast as C++? The question is almost impossible to answer in such a generic formulation. If I were forced to answer I'd say no, it's not. If you ask about some specific situations that might change to "Yes, it is," or "why do we care?"

 

[Crusty]

I didn't use a book to learn what I know of C# since it's oh so similar to Java so I can't really recommend one. All I did was spend time browsing around MSDN learning the Framework and what I could do with it.

 

[suszterpatt]

The two languages aren't really comparable.

C++ is, if not entirely cross-platform (as per Markbnj's post), more universal in a sense. C# was designed specifically for application development over Windows, and it sacrifices efficiency over more luxurious features such as garbage collection. That "C# offers the power of C++ and the simplicity of VB" is more of a marketing line than anything else, but from what little experience I had with C#, it is pretty easy to figure out once you get a couple nudges in the right direction.

 

[JACKDRUID]

C# is not compiled to be read directly by your CPU/os. It is compile to msil (.net version of aseembly language) to be read and executed by .net framwork.

C++ on the other hand, is compiled to be read directly by the CPU/os. so C# will always be slower than C++ in term of speed.

 

[Crusty]

Originally posted by: JACKDRUID

C# is not compiled to be read directly by your CPU/os. It is compile to msil (.net version of aseembly language) to be read and executed by .net framwork.

C++ on the other hand, is compiled to be read directly by the CPU/os. so C# will always be slower than C++ in term of speed.

That's a bad generalization. Yes, there is extra overhead and in most cases the exact same code will be faster in C++ then in C#, but not always. It totally depends on the environment and applications.

 

[suszterpatt]

Originally posted by: Crusty

Originally posted by: JACKDRUID

C# is not compiled to be read directly by your CPU/os. It is compile to msil (.net version of aseembly language) to be read and executed by .net framwork.

C++ on the other hand, is compiled to be read directly by the CPU/os. so C# will always be slower than C++ in term of speed.

That's a bad generalization. Yes, there is extra overhead and in most cases the exact same code will be faster in C++ then in C#, but not always. It totally depends on the environment and applications.

When is C# faster than C++?

 

[JACKDRUID]

Originally posted by: Crusty

Originally posted by: JACKDRUID

C# is not compiled to be read directly by your CPU/os. It is compile to msil (.net version of aseembly language) to be read and executed by .net framwork.

C++ on the other hand, is compiled to be read directly by the CPU/os. so C# will always be slower than C++ in term of speed.

That's a bad generalization. Yes, there is extra overhead and in most cases the exact same code will be faster in C++ then in C#, but not always. It totally depends on the environment and applications.

I'm not trying to misled the op..

the extra layer (.net framework) is actually an advantage in many ways over C++ because it offers C#
1. stability/error checking
2. garbage collection
3. compatibility with other programming languages (Vb.net)
4. cross platform compatibility... supposely you could install .net framework on linux, mac etc to run programs on it... i believe microsoft intentionally hold this back...
5. other stuff... dnt quite remember...

speed isn't everything..
but in term of speed, same code always execute faster without the extra .net framwork overhead.

 

[imported_Dhaval00]

Originally posted by: suszterpatt

Originally posted by: Crusty

Originally posted by: JACKDRUID

C# is not compiled to be read directly by your CPU/os. It is compile to msil (.net version of aseembly language) to be read and executed by .net framwork.

C++ on the other hand, is compiled to be read directly by the CPU/os. so C# will always be slower than C++ in term of speed.

That's a bad generalization. Yes, there is extra overhead and in most cases the exact same code will be faster in C++ then in C#, but not always. It totally depends on the environment and applications.

When is C# faster than C++?

File IO! I could be wrong, and my experience in C++ is <Nullable>. Nevertheless, I just finished writing a huge library in C# [intense IO operations] because the C++ pros at work claimed that C++ was quite "lagging." They're happily using the C# library and claim it is quite a bit faster. As a side note, I used .NET 3.5 - in my opinion, when it comes to performance .NET 3.5 > .NET 2.0 > .NET 1.1. In general, C++ would own C# and JAVA [again... this is an opinion, not a writing on the wall].

Edit: I believe there was an article in Dr. Dobb's Journal a few years ago that compared C#, JAVA, and C++ performance. But they ran the benchmarks using .NET 2.0 Beta, I think.

 

[Crusty]

Originally posted by: suszterpatt

Originally posted by: Crusty

Originally posted by: JACKDRUID

C# is not compiled to be read directly by your CPU/os. It is compile to msil (.net version of aseembly language) to be read and executed by .net framwork.

C++ on the other hand, is compiled to be read directly by the CPU/os. so C# will always be slower than C++ in term of speed.

That's a bad generalization. Yes, there is extra overhead and in most cases the exact same code will be faster in C++ then in C#, but not always. It totally depends on the environment and applications.

When is C# faster than C++?

There is no specific function or operations that are faster or slower, that was my point. It all depends on the application or sometimes it will all depend on which 3rd party libraries you are using. It's pointless to say one languages is faster then the other, because I could surely code up something in C++ that is far slower then the equivalent in C# and vice versa. C# is fast and C++ is fast, choosing one language over the other because of speed is pointless IMO, you've really got to take into account the hundreds of other factors that affect performance.

 

[JACKDRUID]

Originally posted by: Dhaval00

In general, C++ would own C# and JAVA [again... this is an opinion, not a writing on the wall]

.

You are correct here, because compiled code is always faster than almost-compiled code.

 

[Markbnj]

Just remember that when C# executes it is native binary code. The high level syntax is compiled to CIL at assembly build time, and the CIL is JIT compiled to native executable opcodes at runtime. There is overhead in preparing to run the code, but once the code starts executing there is no additional overhead from the extra translation step.

There is, of course, a boatload of overhead from garbage collection and reference lifecycle management, etc.

 

[Kyteland]

Originally posted by: JACKDRUID

Originally posted by: Dhaval00

In general, C++ would own C# and JAVA [again... this is an opinion, not a writing on the wall]

.

You are correct here, because compiled code is always faster than almost-compiled code.

That's not true at all. C# runs native code and not "interpreted" code like you are thinking. The msil is "compiled" when you run it the first time and it uses that every time you execute afterwards. That's what Paint.NET (which is written in C#) is doing when it says "optimizing for your system" for the last few minutes of the install.

This is grossly oversimplified, but C# isn't "slower" because it's interpreted. It's slower because of garbage collection.

Depending on the C++ compiler used, C# can be faster. C++ programs aren't generally optimized for your specific processor, only for the family of processor you are using. In certain circumstances C# will be faster because of this.

In general C++ will have a small speed advantage against C#, but there is no strict yes/no answer to the question. The answer always comes down to what exactly you are trying to accomplish.

 

[JACKDRUID]

That's not true at all. C# runs native code and not "interpreted" code like you are thinking.

No disrespect but interpretation has no meaning in compiled language. It is a phrase used for scripting languages.

The msil is "compiled" when you run it the first time and it uses that every time you execute afterwards.

wrong where would you then stored the compiled information?

msIL is compiled into binary code and put into system memory , it will be kept in memory for the rest of of the execution. That means when you close the program or shut down the machine, and if its not still in system cache, the next time you start the program it will have to be compiled again.

everytime you run the program, it will be slower than C++ compiled code.
the execution may be the same, but it will take longer to start, therefore
COMPILED CODE IS ALWAYS FASTER THAN IL

 

[SunnyD]

The answer is "Yes".

 

[Crusty]

Originally posted by: JACKDRUID

That's not true at all. C# runs native code and not "interpreted" code like you are thinking.

No disrespect but interpretation has no meaning in compiled language. It is a phrase used for scripting languages.

The msil is "compiled" when you run it the first time and it uses that every time you execute afterwards.

wrong where would you then stored the compiled information?

msIL is compiled into binary code and put into system memory , it will be kept in memory for the rest of of the execution. That means when you close the program or shut down the machine, and if its not still in system cache, the next time you start the program it will have to be compiled again.

everytime you run the program, it will be slower than C++ compiled code.
the execution may be the same, but it will take longer to start, therefore
COMPILED CODE IS ALWAYS FASTER THAN IL

In the end you are running compiled code. How you get there has nothing to do with the speed of the application.

 

[Kyteland]

Originally posted by: JACKDRUID

That's not true at all. C# runs native code and not "interpreted" code like you are thinking.

No disrespect but interpretation has no meaning in compiled language. It is a phrase used for scripting languages.

The msil is "compiled" when you run it the first time and it uses that every time you execute afterwards.

wrong where would you then stored the compiled information?

msIL is compiled into binary code and put into system memory , it will be kept in memory for the rest of of the execution. That means when you close the program or shut down the machine, and if its not still in system cache, the next time you start the program it will have to be compiled again.

everytime you run the program, it will be slower than C++ compiled code.
the execution may be the same, but it will take longer to start, therefore
COMPILED CODE IS ALWAYS FASTER THAN IL

I'll admit I gave a poor description of the JIT compiler. You are still wrong that it is always faster. Always is an absolute term, and I gave an example of where C# can be faster. In general C++ is faster, but not always.

 

[JACKDRUID]

Originally posted by: Kyteland
I'll admit I gave a poor description of the JIT compiler. You are still wrong that it is always faster. Always is an absolute term, and I gave an example of where C# can be faster. In general C++ is faster, but not always.

I don't see how your example proves c# can be faster.... do you mind pointing it out?

 

[JACKDRUID]

Originally posted by: Crusty
In the end you are running compiled code. How you get there has nothing to do with the speed of the application.

umm... everytime you run the application it will start faster.... that has nothing to do with speed...?



say you have 2 computers, one boots up faster than the other, and run equally afterwards... and you gonna consider they they are equally as fast?

which one would you buy? if everything else stay constant?

 

[Kyteland]

Originally posted by: JACKDRUID

Originally posted by: Kyteland
I'll admit I gave a poor description of the JIT compiler. You are still wrong that it is always faster. Always is an absolute term, and I gave an example of where C# can be faster. In general C++ is faster, but not always.

I don't see how your example proves c# can be faster.... do you mind pointing it out?

Different processors within the same family aren't all the same. There are cases where C# is faster than a similar C++ program because it can take certain optimizations into account with the JIT compiler that, unless you compile for your exact processor, you aren't going to get with a C++ distributable.

 

[Crusty]

Originally posted by: JACKDRUID

Originally posted by: Crusty
In the end you are running compiled code. How you get there has nothing to do with the speed of the application.

umm... everytime you run the application it will start faster.... that has nothing to do with speed...?



say you have 2 computers, one boots up faster than the other, and run equally afterwards... and you gonna consider they they are equally as fast?

which one would you buy? if everything else stay constant?

You are comparing apples to oranges. Even so, you are talking about time slices that are so small compared the run time of a typical application that it's totally irrelevant. On top of that, just because a program loads faster does not mean that it is always faster.. which goes to my first post about your generalization.

 

[PhatoseAlpha]

You know, last I checked VS did have an option to skip the MSIL entirely and compile native binary code. So C# is only MSIL if you decide to keep it that. If you don't, even that startup into system memory is the same load from disk as a C++ program.


As for the original question, be aware the C# offers simplicity, but it's a different fashion of simplicity the VB. It's programmer's simplicity, not the 'everyone' version VB goes for. Has some advantages, some disadvantages.

And be aware that it's the language that offers both power and simplicity, but they are modal. If you're doing things in C# that genuinely can't be done in VB, there ain't gonna be no simple involved anywhere.

 

[JACKDRUID]

Originally posted by: Crusty
, just because a program loads faster does not mean that it is always faster.. which goes to my first post about your generalization.

whats the difference between a C# binary vs C++ binary?...nothing.. they are all binaries.. if one loads faster, its faster.

Originally posted by Kateland
There are cases where C# is faster than a similar C++ program because it can take certain optimizations into account with the JIT compiler

you can do the same with C++ programs, just compile the code according to your processor. the only difference is the extra compilation everytime you start executing a .net application...

I don't get you guys.. you guys are arguing something even microsoft itself admit being slower due to extra JIT... AS I HAVE STATED ABOVE, THE BENEFIT OUTWEIGHS THE LOST IN SPEED.