.NET Native

[JLogan3o13]

Thought this was an interesting article. Supposed to take C# down to machine code that performs the same as C++, with quite a large performance boost.

http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx

[Mat]

Probably depends on what parts of the framework you use whether you can actually get C++ level performance.

I'd be interested to see what they do with strings in particular, as much of the low level performance with strings is because they are rubbish.

In any case, it's very good for getting C# used more. It's a much better language than C++.

[JohnOne]

Sounds really good, I stopped using C# because it did not compile to native code and started using C/++ instead.

C# is relatively easy, almost as easy as AutoIt3 so I'd love to try it again with .Net Native.

First question that comes to mind, and that I did not find an answer to in the .Net Native FAQ is, When and if they support desktop apps and not just windows store apps, will it mean we can compile dynamic link libraries with .net functionality to native code?

Will be definitely following it's development.

Thanks for the heads up JLo.

[JLogan3o13]

@JohnOne, I was thinking along the same lines. Everything I have seen thus far talks about windows store apps only, but I'm hoping they'll soon announce expansion to more than just that.

[guinness]

Very interesting indeed. Thanks for sharing.

[Richard Robertson]

For those of you who are confused about it being Metro apps only, it's because the desktop version has already been available since the launch of .Net. This is just Metro ngen. http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx

[JohnOne]

Can Ngen compile C# code to native PE file?

Edited April 10, 2014 by JohnOne

[Richard Robertson]

Can Ngen compile C# code to native PE file?

No. ngen takes a complete assembly (exe or dll) and compiles it to platform specific x86/x64 binary and caches it for when the framework is told to execute said assembly. It's meant to be run on the machine that will run the assembly. All assemblies in the global assembly cache are automatically run through ngen as well when registered, if I remember correctly.

[Ascend4nt]

I've been watching the .NET native stuff myself and its sorta renewed interest in C# for me.  I hope they will move ahead and make apps natively compile for O/S's prior to Windows 8 - they had mentioned it was in their plans so keep your fingers crossed.  As far as the 'desktop versoin' being 'ngen', that's baloney.  There is not native compilation yet.

If C#'s cross-platform support via mono and xamarin are fairly trouble-free I might put more effort into learning the language.. (right now D is my baby)

[Richard Robertson]

As far as the 'desktop versoin' being 'ngen', that's baloney.  There is not native compilation yet.

I'm going to stop you right there because ngen is in fact a .Net assembly to machine code compiler. It doesn't give you the binary to do what you want with, but it does compile it. That's as native as any .Net application can get without removing the ability to continue accessing the framework.

It's also worth noting that just running an assembly on the .Net platform (dunno about Mono) will also compile it to a native binary, just piecewise in memory instead of cached to disk.

[Ascend4nt]

Richard, you seem to be changing your argument as you go along - so much so that I'm not entirely sure what you know and what you don't. If we examine your first entry in this thread, you said that .NET native is 'just Metro ngen,' which is entirely inaccurate.  So, let me try to clear things up with the whole NGEN-native-compilation mess.

First, .NET Native is not the same as NGEN 'pre-JIT' force-compiled code.  2 completely different things.

With .NET Native, the compiler creates a binary executable that can be redistributed with nothing more than the MRT.dll (Minimal CLR Runtime - see Compiling Apps with .NET Native).
This is as opposed to an MSIL/CIL-compiled app which requires the entire .NET framework (and isn't native at all).

Now, if we look at NGEN native-compilation, there are a few problems to consider:

1. NGEN must be done forcefully. C# apps are not 'automagically' compiled to native executables.  The normal method for making NGEN work is to initiate it as a final part of a program installation. Distributing a simple C# executable will fail to get any ngen-compiled benefits.
   Even with the "Automatic Native Image Generation" in Windows 8, the program needs to be installed as a Windows Store app or put in the GAC (oh and use .NET 4.5+). (Creating Native Images)
2. NGEN-compiled executables are machine and O/S-specific.  The executable and DLL's can NOT be extracted and used elsewhere.
   Oh, and .NET-specific as well. It still needs the entire .NET (version whatever.xx) architecture support.   
3. NGEN-compiled executables won't be nearly as good as the Microsoft C/C++ compiler backend that is being used in .NET Native.

Basically, NGEN is a very specific optimization step that may or may not be done based on the way a program's INSTALLER is set up. Or - if you are that crazy - as a manual optimization (have fun with the ngen command line!).

So, all in all, equating NGEN to .NET Native is ridiculous. Very, very different things. One is guaranteed-fast natively-compiled code that is portable and requires only the MRT.dll runtime [.NET Native]; the other is a machine-specific installation-specific optimization of MSIL/CIL code that may or may not run faster than JIT-compiled code and also happens to require the entire .NET framework installed (and a specific version at that), plus it isn't portable [NGEN].

Hope that clears the matter up!