Inside .NET Native

Description

What happens when .NET code is statically compiled to machine code (versus runtime compiled via JIT) by the VC++ back end compiler? You get highly optimized binaries that load and run faster than .NET code ever has before. Yes, my friends, .NET has gone native! :)

Today, the .NET team is releasing a preview of their new compiler technology, .NET Native. You can generate .NET native binaries for Windows Store apps only (in this preview). Tune in and meet a few key members of the .NET Native team, PM Mani Ramaswamy and Dev Lead Shawn Farkas. We go deep and Shawn spends quality time at the whiteboard. The team has done a lot of work to get where they are today and no part of .NET has gone untouched, from a new CLR to optimized BCL. This project is a natural extension of the MDIL work that was done for Windows Phone 8. It's all about highly optimized .NET for modern hardware - that the VC++ back end is turning IL into highly optimized machine code is a very, very good thing - for developers and, especially, users!

Note: Shawn and a fellow engineer will be on C9 Live at build on Day 3, so please watch this and prepare questions to ask them live, right here on C9 (details to follow).

All I need to know if this is going to lead to unified cross-platform development, as currently we're stuck with a single cross-platform .NET implementation that lacks any kind of competition, and as you may have guessed, I'm not talking about Microsoft's.

Many of us have already moved away from C#, which is a shame considering the beauty of the language, just because Microsoft insists on having it on their OS environments only.

@MoonStorm: Maybe it will compile native for Linux using Mono converted to Native. Microsoft could offer this as a cloud service . Compile your app native for Linux for x dollars. They make money even if you use Linux so they have a business model for doing this work. It would be stupid to support cross platforms unless money can be made so don't expect it for free.

Stunning Amount of Details. Thanks for the POST. I will use the Beta, just for the Static Testing warnings. This mean that I can see new project "hit" any of the "Beta walls" as the project lifecycle gets rolling. Great work folks. :D

@omario: First, there's a blog post on the .NET blog and an FAQ linked off of aka.ms/dotnetnative. I can't provide links because Channel 9 keeps marking my posts as spam.

With regards to RyuJIT, the .NET CLR team is investing in both static and dynamic code execution strategies. Different scenarios demand different tools, or a blend of both.

With regards to C# for systems programming, you can learn about that by Binging for "M#"

With regards to NGen, .NET Native compiles completely down to native code that doesn't depend upon the CLR installed on the machine. NGen isn't always fully native and requires the CLR and .NET Framework to be present.

@samcov: Server apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.

Check out the FAQ linked off of aka.ms/dotnetnative for more answers to common questions.

Thank you! :-)This is awesome, the best news of Build for me. More important than the performance, which is great by the way, this seems like a start to (finally) port .Net across multiple platforms (Android/iOS in the future maybe?!) A questions though:

How does this relate to Universal Apps? I mean why would anyone use that while apparently, in the future .Net Native is going to support both phone and store apps, and also desktop and server? This becomes much more universal, right?

Does the final native binary contain profiling hooks. I understand precompiling to the target architecture for faster startup. But are there profiling hooks to perform runtime profile based optimizations (*) or is it at this point no different than a C++ application compiled statically.

(*) Class Hierarchy Analysis, method devirtualization, inline caches, lock elision, JIT is a lot more than just dynamically compiling from IR to native, a large part of JIT runtimes also dynamically optimize. Curious if any of that is available when using .NET NATIVE.

This great work, particularly the fact that all optimizations are agnostic to app developers, hopefully does not add significant time to publishing process. Question I have is when is this goodness coming to cloud/azure and server/web apps ?

I have a question. Does this mean that Visual Studio team will be using this technology when compiling the IDE itself, so that the startup times and performance of Visual Studio can take advantage of these benefits?

@Sander van Rossen: As of today, the .NET Native Preview links in all library code and passes it to the C++ optimizer to perform global analysis and optimizations that will include locality optimizations as well.

Can I press some further on that please? To be clear, the native binary has (will-have?) provisions to Dynamically Profile (via ETW?) and then patch call sites based on Dynamic Compilation? So I can expect a frequently executed call-stack say from within a loop to be inlined dynamically

@bank kus: Sorry if I wasn't clear. My statement was that the .NET team was supporting both static and dynamic compilation technologies (with different products)

Since .NET Native is static compilation, all code has to be compiled statically and generated at compile time. Based on runtime characteristics, one may be able to conditionally exercise the more optimal code path, but all code has to be generated before hand.

@ramaswamy: Thanks for the response. I saw your video as well and I do get that you guys are working on something for traditional desktop applications as well BUT may not be able to disclose specifics at this point.

I was asking about a timeline because I'm working on a commercial application and we're thinking about leaving C# in-favor of C++ - primarily because of performance and IL decompilation issues. If there is a chance that .NET Native for Desktop apps could be out within next 4-5 months...then we'll definitely stick with C#.

Is the performance gain only contained in the startup of the application? Will a statically compiled application run at the same speeds as a JIT app that has been compiled?

Not trying to discount the news in any way, but I'm just curious. It seems like this would improve things, and the biggest thing IMO is the elimination of need for the .Net Framework install. The idea of a completely self contained application is nice. I haven't released a desktop application for quite a while, but I remember the framework install/upgrade being a pain point for customers, as strange as that sounds.

Totally diggin JeremyMorgan's Post!Is the speedup only at startup or also at runtime?Will we in the future be able to deploy .Net-Framework Libs just with our binaries so that there is no need for a pre-installed .Net-Framework?All that sounds so promising! C# &. Net building the Bigroad for the future Development : )

Would love to see a way to statically link those parts of the .NET framework that I'm using into a native code EXE or DLL, allowing it to be used to write shell extensions, office extensions and other kinds of native components that have previously been hamstrung by heavyweight side-by-side runtime versioning issues.

Tell me if this is an ill-founded question, but, does .NET Native, when it supports normal desktop apps, mean that native C++, even C++11 and beyond, will finally be superseded? C++ is great, I love C++, but I also love the simplicity and ease of doing things in C# (thanks to the vast library of objects and types of .NET which C++ does not have).

Put another way - does .Net Native enable a developer to do everything that a native C++ developer can do? Write OS kernels, for example?

Curious how this will impact SQL Server's support for .NET code. The world pretty successfully hid it's appreciation of SQL support for .NET code, but if the performance penalty visa-vie C++ could be mitigated, a lot of finance's arbitrarily complex calculations could be triggered only for updated or added rows, making for an easy to manage coherent data set without the need for massive and redundant bulk recalculations.

BTW, has anyone at MSFT noticed that while Linux has massively better support for timers, the choice of database there is pretty much Larry Ellison and larry ellison (mysql)? Could somebody P-L-E-A-S-E port SQL Server to Linux???

Of course Visual Basic 6 (VB6) has done this for years. It combines better productivity (by using the VB6 RAD) with the performance of C++ (by using the C++ compiler).

Pre-compiling C#, rather than JIT compiling, will speed up loading time, though not necessarily performance. This is long overdue.Of course, the backend compiler for this is the C++ compiler – just like the VB6 programming language has used since 1998 !

The big question is, can these so called "native apps" be reverse engineered to near source code just as regular .net MSIL executables can? If so, I don't see any benefit for us developers apart from a little speed increase on sluggish Windows tablets. Another microsoft initiative that was sprung onto the developer community without consultation. Like the other guy said, why haven't you already made native compilation available for thick desktop .Net applications? Poor planning and strategy from microsoft yet again.

@Alexander77: As I know when any app starts up for the first time, the IL code gets converted to native code, and then the app runs as good as native apps. The start-up time is faster for native apps. Libraries can benefit by going native. Native libraries run in the shared process space and can be shared by multiple apps (unlike managed libraries which run in the private process space of the app).