Faster than native code?
Okay, this is something that has really been bothering me.
I don't hate .NET. I even had a job for 4 years writing C# applications. (Well, it was more of an internship, but I did get paid.) I am just not really a fan of really high level languages. Its really just a matter of personal taste. They have their place. But lower level languages like C and C++ also have their place and for whatever reason, there are people who don't want to acknowledge this. They will then give me a list of reasons why .NET is better such as automatic memory management, type safety, security against things like buffer overrun attacks, and stuff like that. These are all perfectly good and valid reasons to use .NET or any managed code environment over a language or tool chain that compiles to native code. I accept that. Doesn't change the fact that you can't always do everything in .NET that you can with native code and I tell them this.
But there is one claim that I hear frequently that just bothers me. I have heard this claim on several occasions on the Microsoft website, and by other people; that not only are programs written for .NET on par performance wise with programs that are compiled to native code by a proper optimizing compiler, but that managed code can sometimes even be faster than native code.
I normally dismiss this claim on the the grounds that .NET code ultimately compiles to native code anyway and it doesn't make sense to say that native code can run faster than itself; Since in .NET everything is a class, there is typically multiple levels of inheritance that has to be dealt with when programmatically manipulating anything in the context of .NET; Built in type checking and the heavy use of metadata in .NET provides even more overhead; an most of those things are simply not present in compilers that produce native code directly which means that 100% of the CPU time (ignoring context switches and things like that) goes to actually carrying out the tasks defined in your program where as with native code a major portion of the CPU time is spent on type safety, the garbage collector, reading metadata, compiling MSIL code to native code, and other stuff. Therefore it would make sense that the managed code would inherently have to take longer because it is doing more stuff.
But, still, I don't know everything and maybe there is something I don't know that allows managed code to somehow beat native code. I mean I heard the explanation that since you are doing just in time compilation, the .NET runtime can optimize the code on the fly to get the best results for that specific machine/environment where as native code is one-size-fits-all, but I have a hard time believing that desktop computers really differ enough from eachother for that to make a difference. So that is my question. Is there any truth to this claim of managed code being faster than native code? And if there is, is it something that is practical or is it just theoretical?
I don't hate .NET. I even had a job for 4 years writing C# applications. (Well, it was more of an internship, but I did get paid.) I am just not really a fan of really high level languages. Its really just a matter of personal taste. They have their place. But lower level languages like C and C++ also have their place and for whatever reason, there are people who don't want to acknowledge this. They will then give me a list of reasons why .NET is better such as automatic memory management, type safety, security against things like buffer overrun attacks, and stuff like that. These are all perfectly good and valid reasons to use .NET or any managed code environment over a language or tool chain that compiles to native code. I accept that. Doesn't change the fact that you can't always do everything in .NET that you can with native code and I tell them this.
But there is one claim that I hear frequently that just bothers me. I have heard this claim on several occasions on the Microsoft website, and by other people; that not only are programs written for .NET on par performance wise with programs that are compiled to native code by a proper optimizing compiler, but that managed code can sometimes even be faster than native code.
I normally dismiss this claim on the the grounds that .NET code ultimately compiles to native code anyway and it doesn't make sense to say that native code can run faster than itself; Since in .NET everything is a class, there is typically multiple levels of inheritance that has to be dealt with when programmatically manipulating anything in the context of .NET; Built in type checking and the heavy use of metadata in .NET provides even more overhead; an most of those things are simply not present in compilers that produce native code directly which means that 100% of the CPU time (ignoring context switches and things like that) goes to actually carrying out the tasks defined in your program where as with native code a major portion of the CPU time is spent on type safety, the garbage collector, reading metadata, compiling MSIL code to native code, and other stuff. Therefore it would make sense that the managed code would inherently have to take longer because it is doing more stuff.
But, still, I don't know everything and maybe there is something I don't know that allows managed code to somehow beat native code. I mean I heard the explanation that since you are doing just in time compilation, the .NET runtime can optimize the code on the fly to get the best results for that specific machine/environment where as native code is one-size-fits-all, but I have a hard time believing that desktop computers really differ enough from eachother for that to make a difference. So that is my question. Is there any truth to this claim of managed code being faster than native code? And if there is, is it something that is practical or is it just theoretical?
I think it's because a JIT compiler can sometimes produce better-optimized code than an AOT compiler.
Last edited on
There are two things that lend "truth" to this.
One is as chrisname said. Native code is typically compiled to work on a range of processors, meaning that an advanced opcode is skipped in lieu of something that will work on more kinds of processors. When compiling with C or C++, you can adjust this to use stuff for your hardware, but this limits who can execute your code.
In change, a runtime environment can safely assume that it can compile using special instructions available on your processor every time, and so it does. Hence, the resulting machine code is faster. Notice how this is a subtle equivocation fallacy: the term "native" has two meanings here, but it is used as if it has the same meaning. "Native" code is machine code. But the advertisements mean "code already compiled to native code" vs code yet to be compiled JIT.
Two is that certain operations are common and are specifically optimized to work in a managed environment. Again, this typically results in certain things that would be done one way for good effect, whereas there are many ways to do it -- when you give the programmer all the tools he doesn't always do things the most efficient way. Likewise, certain design criteria of, say, C++ or the STL don't lend themselves to the most efficient way of doing things, but the most useful in the most contexts. Managed code can accomodate this, whereas humans are not so good at knowing everything to accomodate it.
I still think that such advertising is a bit slimy, but, well, that's that.
Hope this helps.
One is as chrisname said. Native code is typically compiled to work on a range of processors, meaning that an advanced opcode is skipped in lieu of something that will work on more kinds of processors. When compiling with C or C++, you can adjust this to use stuff for your hardware, but this limits who can execute your code.
In change, a runtime environment can safely assume that it can compile using special instructions available on your processor every time, and so it does. Hence, the resulting machine code is faster. Notice how this is a subtle equivocation fallacy: the term "native" has two meanings here, but it is used as if it has the same meaning. "Native" code is machine code. But the advertisements mean "code already compiled to native code" vs code yet to be compiled JIT.
Two is that certain operations are common and are specifically optimized to work in a managed environment. Again, this typically results in certain things that would be done one way for good effect, whereas there are many ways to do it -- when you give the programmer all the tools he doesn't always do things the most efficient way. Likewise, certain design criteria of, say, C++ or the STL don't lend themselves to the most efficient way of doing things, but the most useful in the most contexts. Managed code can accomodate this, whereas humans are not so good at knowing everything to accomodate it.
I still think that such advertising is a bit slimy, but, well, that's that.
Hope this helps.
Another thing is that the managed environment is more limited when it comes to what you can do (I think about low-level operations here). In result, the compiler can make more assumptions what sometimes allows it to produce better optimized code. Simplest example: pointer aliasing.
Okay, that all sounds reasonable. But even with the slight boost in performance you get from being able to produce optimized code for that particular machine and all that, wouldn't the overhead of the garbage collector, the type safety checks, the need to actually do the compilation on the fly in the first place and all that end up negating it anyway?
| I still only use C# because it feels so elegant (to me). |
I like C++ because it was designed by a humble and intelligent company that well deserves respect. It's not entirely subject to a monkey business, like Microsoft's C# or Oracle's Java. In the context of the language itself, I think C++ is more robust and usable. When you're stuck with utility that works just a little bit differently than what you need, it can build up and ruin the final product all together. That's .NET
| But...wouldn't the overhead of the garbage collector, the type safety checks, the need to actually do the compilation on the fly in the first place and all that end up negating it anyway? |
| I like C++ because it was designed by a humble and intelligent company that well deserves respect. |
I like C++ too, but not for those reasons (which I don't believe).
More fun reading, C++ Optimization Strategies and Techniques:
http://www.tantalon.com/pete/cppopt/main.htm
C++ wasn't designed by AT&T/Bell, it was designed by Bjarne Stroustrup. I think he was (and is) a professor at a university in Texas at the time.
Also, don't get me wrong, I don't like Microsoft (or any company, to be honest), but I do think C# is an excellent programming language.
Also, don't get me wrong, I don't like Microsoft (or any company, to be honest), but I do think C# is an excellent programming language.
Last edited on
closed account (z05DSL3A)
| chrisname wrote: |
|---|
| C++ wasn't designed by AT&T/Bell, it was designed by Bjarne Stroustrup. I think he was (and is) a professor at a university in Texas at the time. |
Was he not at Bell Labs when he started work on C++?
Regardless of who Bjarne Stroustrup worked for at the time, is not the standard now dictated by an independent committee?
EDIT: I should point out that I am not trying to condemn languages like C# either.
EDIT: I should point out that I am not trying to condemn languages like C# either.
Last edited on
Really? Huh. Learn something every day :)
@Xander314,
Yeah, and that's my biggest problem with C#. However, MSDN has excellent documentation, Mono has good-enough documentation for things like Gtk# which obviously aren't mentioned on MSDN in favour of Windows.Forms, and the language itself is great.
@Xander314,
Yeah, and that's my biggest problem with C#. However, MSDN has excellent documentation, Mono has good-enough documentation for things like Gtk# which obviously aren't mentioned on MSDN in favour of Windows.Forms, and the language itself is great.
Topic archived. No new replies allowed.