Native vs. .NET
- Thread starter ronblack
- Start date
Well, guess what:
* .NET applications are applications written in a .NET language and running on the .NET framework.
* Native applications run native (on windows) without the .NET framework.
.NET applications are also mostly runtime compiled and not precompiled, thugh there are exceptions.
* .NET applications are applications written in a .NET language and running on the .NET framework.
* Native applications run native (on windows) without the .NET framework.
.NET applications are also mostly runtime compiled and not precompiled, thugh there are exceptions.
A .NET application needs the .NET Framework to run. You can say that a .NET App runs on top of this Framework. A native App run on top of the OS â it doesnât needs the .NET framework to run.
Please keep in mind that this is only a very easy approach to show the differences from a user point of view. If you want to get a bit closer you should have a look at http://www.microsoft.com/NET/ or http://en.wikipedia.org/wiki/.NET_Framework
Daniel
Please keep in mind that this is only a very easy approach to show the differences from a user point of view. If you want to get a bit closer you should have a look at http://www.microsoft.com/NET/ or http://en.wikipedia.org/wiki/.NET_Framework
Daniel
Nice bullshit.
You are aware that:
* MSIL is only executable AT LEAST with jit?
* MSIL can actually be native
Bad news. Not only is there a tool in the .NET framework to natively compile assemblies (ngen - generates a native image - i.e. machine code), there are also various tools that will happily compile your application to native code.
There HAVE been nice tests demonstrating well written .NET code executing at comparable speeds to C / C++ code.
I love when people make stupid comments without the basics of research first. Keeps me in business fixing up the mess people like you create
You are aware that:
* MSIL is only executable AT LEAST with jit?
* MSIL can actually be native
Bad news. Not only is there a tool in the .NET framework to natively compile assemblies (ngen - generates a native image - i.e. machine code), there are also various tools that will happily compile your application to native code.There HAVE been nice tests demonstrating well written .NET code executing at comparable speeds to C / C++ code.
I love when people make stupid comments without the basics of research first. Keeps me in business fixing up the mess people like you create
Quote from NetTecture:
Nice bullshit.
You are aware that:
* MSIL is only executable AT LEAST with jit?
* MSIL can actually be native
There HAVE been nice tests demonstrating well written .NET code executing at comparable speeds to C / C++ code.
I love when people make stupid comments without the basics of research first. Keeps me in business fixing up the mess people like you create
While ngen can create native images, you still need the CLR to run the executable and you lose the option of the CLR dynamically optimizing your assemblies based on the native environment. The only advantage real advantage is start up time.
There are tests comparing C# with native performance (C/C++/ASM), but it's highly dependent on the actual work being done (whether the platform can optimize). I agree the performance trade offs are usually negligible for ET's audience, but it's not a good blanket statement. You also have to consider the way C# code is optimized to compete with the native binaries in many of these performance tests, often it renders the high level abstractions useless and defeats the point of using C# in the first place.
I made no blanket statements.
The poster made a nice list of performance degradation and counted MSIL (.net bytecode) last. That is what I objected to. Demonsration of ignorance.
You are right, there are SOME things .NET compilation currently does worse - matrix operations are one particular item (not using SSE).
You are wrong in the need for the .NET framework, though. There ARE tools that will produce one exe file that does not need the framework, pulling all the necessary code into the exe
Check http://www.remotesoft.com/ - a native compiler for .NET that even rmeoves the need for the .NET framework by pulling it in
The poster made a nice list of performance degradation and counted MSIL (.net bytecode) last. That is what I objected to. Demonsration of ignorance.
You are right, there are SOME things .NET compilation currently does worse - matrix operations are one particular item (not using SSE).
You are wrong in the need for the .NET framework, though. There ARE tools that will produce one exe file that does not need the framework, pulling all the necessary code into the exe
Check http://www.remotesoft.com/ - a native compiler for .NET that even rmeoves the need for the .NET framework by pulling it in
Here is something to think about:
Assembly is slowest and costs most.
Native is faster, but still dead slow and costs middle.
.NET, Java etc. are fastest and cheapest.
What I talk about ? Here is a hint: try developping something like - hm - NinjaTrader in assembler
Assembly is slowest and costs most.
Native is faster, but still dead slow and costs middle.
.NET, Java etc. are fastest and cheapest.
What I talk about ? Here is a hint: try developping something like - hm - NinjaTrader in assembler
Quote from NetTecture:
I made no blanket statements.
The poster made a nice list of performance degradation and counted MSIL (.net bytecode) last. That is what I objected to. Demonsration of ignorance.
You are right, there are SOME things .NET compilation currently does worse - matrix operations are one particular item (not using SSE).
You are wrong in the need for the .NET framework, though. There ARE tools that will produce one exe file that does not need the framework, pulling all the necessary code into the exe
Check http://www.remotesoft.com/ - a native compiler for .NET that even rmeoves the need for the .NET framework by pulling it in
Thanks. I think I heard of that one on an episode of .NET Rocks. Do you have any experience with this linker/compiler? There isn't much of any real information on their site, but I'd be interested to see some hard data, as far as executable size, runtime performance, etc.