Native vs. .NET

Discussion in 'Trading Software' started by ronblack, Aug 26, 2009.

  1. ronblack

    ronblack

    I was reading an article on trading software (I lost the link) and they mentioned native vs. .NET applications. Can someone explain the difference? Thanks
     
  2. 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.
     
  3. 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
     
  4. First there was assembly.
    Then there was native.
    Then there was jit.
    Then there was MSIL (.net)

    Fastest at the top, slowest at the bottom.

    However MSFT assure us that MSIL is as fast as assembly of course !
     
  5. 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 ;)
     
  6. 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.
     
  7. 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 ;)
     
  8. 1) Assembly is fastest
    2) Native is slower
    3) Everything else is slower

    If MSIL is as fast as native well done MSFT.
     
  9. 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 ;)
     
  10. 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.
     
    #10     Aug 28, 2009