5 ms·

.NET Native Performance

85 points by Artemis2 11y ago

Lx1oG-AWb6h_ZG0 11y ago
How do .Net Native and .Net Core interact? I remember there was a post about .Net Corr here a while back, and one of the advantages touted was the ability for the .Net team to push out security updates for framework dlls via Windows Update that your app would automatically use because of the CLR Cache. How will .Net Native deal with this sort of stuff if the framework parts are directly baked into the executable?
- batou 11y ago
  Your app is compiled from MSIL to native on MS's servers if it's like Windows Phone. I think they can recompile everything if a dependency changes for example and push a new app version for you.
  - gdc 11y ago
    It happens on your local machine. There's a checkbox to enable / disable it.
    - runfaster2000 11y ago
      It happens in both places. You can (and should) test with .NET Native enabled on your local machine. You still upload IL to the Windows Store, and the final native compilation is done there. The Windows Store uses the same .NET Native SDK as ships with Visual Studio.
- runfaster2000 11y ago
  .NET team member here ... We like to think of .NET Native as a native tool-chain for .NET Core. I say "a" because the Xamarin and Unity (IL2CPP) tool-chains are equally applicable (and we've talked to them about it). The core framework libraries (CoreFX) - https://github.com/dotnet/corefx https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently. Today, .NET Native and .NET Core use two different runtimes, MRT and CoreCLR, respectively. MRT expands to the extremely creative "managed runtime". Colloquially, we call it "Mr. T". Earlier in the project, everyone working on .NET Native had posters of Mr. T (yes, that one) on our doors. Mohawks were entirely optional on the parts of team members. MRT was built for static ahead-of-time (AOT) compilation. It is the child of the Redhawk project (http://www.zdnet.com/article/microsoft-codename-redhawk-lives-in-windows-8/ http://www.zdnet.com/article/microsoft-codename-redhawk-live...). Redhawk was built to be a .NET-esque (using C# + extensions) systems programming environment. MRT was built to have many of the same benefits, but be compatible with .NET (not just "esque") and support nothing less, nothing more than C#. CoreCLR is a child of the .NET Framework CLR. CLR (and by extention, CoreCLR) was built for dynamic execution, with a JIT. It supports AOT compilation in the pre-jit/NGEN sense. The GC is the primary shared component between the two (MRT, CLR/CoreCLR) runtimes. We plan to bring static compilation to more scenarios, however, we strongly believe that both JIT and (real) AOT are legitimate and compelling technologies and experiences and both are on our long-term roadmap. We'd like to leave the compilation choice/appraoch up to our users/customers. Novel idea, eh? We have a lot of fun runtime and compiler tech on the team. It's a fun place to work. Much of it is now open source, meaning that we get to work on this fun tech in the open. This is our latest compiler announcement: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx#ryujit http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing....
  - MichaelGG 11y ago
    Thanks for posting! Why only target C#? Is Net Native using C# source instead of IL? Or does it only support a subset of IL that C# currently emits? (No tail calls, no cpblk)? Why isn't this just rolled into ngen? Or run as a second stage JIT, caching the results to disk? I cannot think of any scenarios where anyone wants to re-JIT every time they start a program. At least not on desktop and server scenarios (maybe some embedded system with no storage space). Or, I guess the real question is: apart from reflection which other features don't work the same on .NET Native?
    - runfaster2000 11y ago
      My post had more C# bias than appropriate. .NET Native also supports VB. See: https://msdn.microsoft.com/en-us/dotnetnative https://msdn.microsoft.com/en-us/dotnetnative. I don't think it yet supports F#, but that's likely on the roadmap. Reflection is supported on .NET Native Native. See: http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native-deep-dive-dynamic-features-in-static-code.aspx http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native.... Reflection.Emit is not. There are effectively three codegen strategies: JIT, pre-jit and static compilation/AOT. They all have their own characteristics and reasons why they are a good choice. I can see that you have depth here, but I'm going to provide an answer with more context, for a broader audience. - JIT has the most flexibility since the code is generated (you guessed it) just in time. This means that the code generated can be specialized in terms of hardware or use a layered approach to codegen (prefer throughput and then CQ for hotter methods). It is also the best for versioning, since the code is always generated in terms of the actual dependencies, as opposed to the ones you happened to compile with. - Pre-JIT can be very high performance since you don't have to pay for JIT and other related costs up-front, as is the case with NGEN. Depending on the code generated, it may be subject to the fragile base class problem: https://en.wikipedia.org/wiki/Fragile_base_class https://en.wikipedia.org/wiki/Fragile_base_class, as is the case with NGEN. MDIL is also subject to it, but we made the cost to regenerate images very low. There can be a problem of when to generate the images and where to store them. These two issues have been a constant design challenge for us (mostly the former). At least on the surface, pre-jit is much cheaper than AOT, particularly since you can rely on a JIT for the code that you can generate deterministically (at least into a single bit of code) ahead of time (think generics). ReadyToRun (https://github.com/dotnet/coreclr/issues/227 https://github.com/dotnet/coreclr/issues/227) is a project we're working that makes NGEN/CrossGen images more resilient to the fragile base class problem. - AOT can be very high performance, for the same reasons. We've found that it is even higher performance since you can skip a number of architecural requirements for a dynamic runtime environment. If you couple this with app-local framework and runtime distribution, as is the case with .NET Native, then you also skip the fragile base class problem. Building a high-performance industrial quality AOT system with a fabulous developer experience is a fantastic computer science challenge. We've certainly found it to be that. We're several years into AOT investments and we're finding that it is paying off.
- Eyas 11y ago
  My understanding from reading the many blog posts and some of the GitHub repo discussions: .NET Core is the refactored .NET libraries which are used by many projects, one of which is .NET Native. The cross platform work is also only in .NET Core and not the .NET Framework, the new ASP.NET is as well. The open source .NET Core provides a subset of the libraries in the .NET Framework. Namely, .NET Core does not include WinForms, etc. The open source effort of .NET Core is divided into CoreFX (C# libraries) and CoreCLR "Runtime" (JIT, GC, C++ libraries, for the most part). .NET Native is built on .NET Core, but does not depend on the runtime (unclear to me what that means vis-a-vis GC, and C++ libraries, which I assume are still there... but certainly no JIT).
velox_io 11y ago
It's a shame it's only for Windows Store Apps. I'd love to see what this can do to other .Net programs. Although saying that, it's quite amazing how much of the core libraries are written in C#, you what have thought it would be wrappers over C++ libraries.
- andzt 11y ago
  I would have loved to see this a few years ago on Windows Forms/WPF apps as well. Performance was an issue as the libraries continued to expand and grow with additional interdependencies. .NET Reflector came in handy once or twice to copy out a few library functions to avoid adding another reference dll.
- CmonDev 11y ago
  I would like it on Android and iOS via updated Mono.
joshuapants 11y ago
So this post is about a year old. Looking at the .NET blog, I don't see any direct follow-ups. How did this pan out?
- alyx 11y ago
  Shipped with VS 2015, https://msdn.microsoft.com/en-us/vstudio/dotnetnative https://msdn.microsoft.com/en-us/vstudio/dotnetnative
- mhomde 11y ago
  All Windows (Phone) 10 apps will per default be compiled with .Net Native
  - PaulHoule 11y ago
    Are there going to be any Windows Phone 10 phones given that Microsoft is pulling out of phones?
    - mhomde 11y ago
      I think you've misinterpreted, they're not pulling out of phones... just focusing on a fewer number of phones. Seems like a new flagship is coming around September If you think MS ever would "pull out" of mobile and be satisfied with "being a guest in someone else house", your insane :)
      - joshuapants 11y ago
        > they're not pulling out of phones... just focusing on a fewer number of phones Fewer models, to be exact. In contrast to their old strategy of saturating the low end with multitudes of confusingly numbered Lumias they're consolidating into three distinct lines. Presumably they want to have volume!
- runfaster2000 11y ago
  You can see a few mentions to .NET Native and UWP here: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx#net-core http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing.... .NET Native will RTM on 7/29 as the basis of the .NET tools for Windows 10 UWP apps
CmonDev 11y ago
> "Pay-for-Play Reflection" Native and allowing reflection? I am now much less interested in M#.
- pcunite 11y ago
  M# might have given us the "delete" keyword. But yes, this could be nice.
deleted 11y ago
[deleted]
PaulHoule 11y ago
It strikes me a lot like the way Google has tried out various sorts of VMs for Java in android.
simfoo 11y ago
Looking at MSDN and trying to find any setting about it in VS 2015, it seems .NET Native is only supported in Windows Store Apps. What about standard Winforms or Console Applications?
- sandyarmstrong 11y ago
  The end of the article says: "The current preview only supports Windows Store apps written in C# and running on x64 or ARM machines, but we’re hard at work adding support for other scenarios."
platz 11y ago
Compiles .NET/C# to native code using LLVM framework: https://github.com/xen2/SharpLang https://github.com/xen2/SharpLang

85 points by Artemis2 11y ago

How do .Net Native and .Net Core interact? I remember there was a post about .Net Corr here a while back, and one of the advantages touted was the ability for the .Net team to push out security updates for framework dlls via Windows Update that your app would automatically use because of the CLR Cache. How will .Net Native deal with this sort of stuff if the framework parts are directly baked into the executable?

batou 11y ago
Your app is compiled from MSIL to native on MS's servers if it's like Windows Phone. I think they can recompile everything if a dependency changes for example and push a new app version for you.
- gdc 11y ago
  It happens on your local machine. There's a checkbox to enable / disable it.
  - runfaster2000 11y ago
    It happens in both places. You can (and should) test with .NET Native enabled on your local machine. You still upload IL to the Windows Store, and the final native compilation is done there. The Windows Store uses the same .NET Native SDK as ships with Visual Studio.
runfaster2000 11y ago
.NET team member here ... We like to think of .NET Native as a native tool-chain for .NET Core. I say "a" because the Xamarin and Unity (IL2CPP) tool-chains are equally applicable (and we've talked to them about it). The core framework libraries (CoreFX) - https://github.com/dotnet/corefx https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently. Today, .NET Native and .NET Core use two different runtimes, MRT and CoreCLR, respectively. MRT expands to the extremely creative "managed runtime". Colloquially, we call it "Mr. T". Earlier in the project, everyone working on .NET Native had posters of Mr. T (yes, that one) on our doors. Mohawks were entirely optional on the parts of team members. MRT was built for static ahead-of-time (AOT) compilation. It is the child of the Redhawk project (http://www.zdnet.com/article/microsoft-codename-redhawk-lives-in-windows-8/ http://www.zdnet.com/article/microsoft-codename-redhawk-live...). Redhawk was built to be a .NET-esque (using C# + extensions) systems programming environment. MRT was built to have many of the same benefits, but be compatible with .NET (not just "esque") and support nothing less, nothing more than C#. CoreCLR is a child of the .NET Framework CLR. CLR (and by extention, CoreCLR) was built for dynamic execution, with a JIT. It supports AOT compilation in the pre-jit/NGEN sense. The GC is the primary shared component between the two (MRT, CLR/CoreCLR) runtimes. We plan to bring static compilation to more scenarios, however, we strongly believe that both JIT and (real) AOT are legitimate and compelling technologies and experiences and both are on our long-term roadmap. We'd like to leave the compilation choice/appraoch up to our users/customers. Novel idea, eh? We have a lot of fun runtime and compiler tech on the team. It's a fun place to work. Much of it is now open source, meaning that we get to work on this fun tech in the open. This is our latest compiler announcement: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx#ryujit http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing....
- MichaelGG 11y ago
  Thanks for posting! Why only target C#? Is Net Native using C# source instead of IL? Or does it only support a subset of IL that C# currently emits? (No tail calls, no cpblk)? Why isn't this just rolled into ngen? Or run as a second stage JIT, caching the results to disk? I cannot think of any scenarios where anyone wants to re-JIT every time they start a program. At least not on desktop and server scenarios (maybe some embedded system with no storage space). Or, I guess the real question is: apart from reflection which other features don't work the same on .NET Native?
  - runfaster2000 11y ago
    My post had more C# bias than appropriate. .NET Native also supports VB. See: https://msdn.microsoft.com/en-us/dotnetnative https://msdn.microsoft.com/en-us/dotnetnative. I don't think it yet supports F#, but that's likely on the roadmap. Reflection is supported on .NET Native Native. See: http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native-deep-dive-dynamic-features-in-static-code.aspx http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native.... Reflection.Emit is not. There are effectively three codegen strategies: JIT, pre-jit and static compilation/AOT. They all have their own characteristics and reasons why they are a good choice. I can see that you have depth here, but I'm going to provide an answer with more context, for a broader audience. - JIT has the most flexibility since the code is generated (you guessed it) just in time. This means that the code generated can be specialized in terms of hardware or use a layered approach to codegen (prefer throughput and then CQ for hotter methods). It is also the best for versioning, since the code is always generated in terms of the actual dependencies, as opposed to the ones you happened to compile with. - Pre-JIT can be very high performance since you don't have to pay for JIT and other related costs up-front, as is the case with NGEN. Depending on the code generated, it may be subject to the fragile base class problem: https://en.wikipedia.org/wiki/Fragile_base_class https://en.wikipedia.org/wiki/Fragile_base_class, as is the case with NGEN. MDIL is also subject to it, but we made the cost to regenerate images very low. There can be a problem of when to generate the images and where to store them. These two issues have been a constant design challenge for us (mostly the former). At least on the surface, pre-jit is much cheaper than AOT, particularly since you can rely on a JIT for the code that you can generate deterministically (at least into a single bit of code) ahead of time (think generics). ReadyToRun (https://github.com/dotnet/coreclr/issues/227 https://github.com/dotnet/coreclr/issues/227) is a project we're working that makes NGEN/CrossGen images more resilient to the fragile base class problem. - AOT can be very high performance, for the same reasons. We've found that it is even higher performance since you can skip a number of architecural requirements for a dynamic runtime environment. If you couple this with app-local framework and runtime distribution, as is the case with .NET Native, then you also skip the fragile base class problem. Building a high-performance industrial quality AOT system with a fabulous developer experience is a fantastic computer science challenge. We've certainly found it to be that. We're several years into AOT investments and we're finding that it is paying off.
Eyas 11y ago
My understanding from reading the many blog posts and some of the GitHub repo discussions: .NET Core is the refactored .NET libraries which are used by many projects, one of which is .NET Native. The cross platform work is also only in .NET Core and not the .NET Framework, the new ASP.NET is as well. The open source .NET Core provides a subset of the libraries in the .NET Framework. Namely, .NET Core does not include WinForms, etc. The open source effort of .NET Core is divided into CoreFX (C# libraries) and CoreCLR "Runtime" (JIT, GC, C++ libraries, for the most part). .NET Native is built on .NET Core, but does not depend on the runtime (unclear to me what that means vis-a-vis GC, and C++ libraries, which I assume are still there... but certainly no JIT).

velox_io 11y ago

It's a shame it's only for Windows Store Apps. I'd love to see what this can do to other .Net programs. Although saying that, it's quite amazing how much of the core libraries are written in C#, you what have thought it would be wrappers over C++ libraries.

andzt 11y ago
I would have loved to see this a few years ago on Windows Forms/WPF apps as well. Performance was an issue as the libraries continued to expand and grow with additional interdependencies. .NET Reflector came in handy once or twice to copy out a few library functions to avoid adding another reference dll.
CmonDev 11y ago
I would like it on Android and iOS via updated Mono.

joshuapants 11y ago

So this post is about a year old. Looking at the .NET blog, I don't see any direct follow-ups. How did this pan out?

alyx 11y ago
Shipped with VS 2015, https://msdn.microsoft.com/en-us/vstudio/dotnetnative https://msdn.microsoft.com/en-us/vstudio/dotnetnative
mhomde 11y ago
All Windows (Phone) 10 apps will per default be compiled with .Net Native
- PaulHoule 11y ago
  Are there going to be any Windows Phone 10 phones given that Microsoft is pulling out of phones?
  - mhomde 11y ago
    I think you've misinterpreted, they're not pulling out of phones... just focusing on a fewer number of phones. Seems like a new flagship is coming around September If you think MS ever would "pull out" of mobile and be satisfied with "being a guest in someone else house", your insane :)
    - joshuapants 11y ago
      > they're not pulling out of phones... just focusing on a fewer number of phones Fewer models, to be exact. In contrast to their old strategy of saturating the low end with multitudes of confusingly numbered Lumias they're consolidating into three distinct lines. Presumably they want to have volume!
runfaster2000 11y ago
You can see a few mentions to .NET Native and UWP here: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx#net-core http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing.... .NET Native will RTM on 7/29 as the basis of the .NET tools for Windows 10 UWP apps

CmonDev 11y ago

> "Pay-for-Play Reflection" Native and allowing reflection? I am now much less interested in M#.

pcunite 11y ago
M# might have given us the "delete" keyword. But yes, this could be nice.

deleted 11y ago

[deleted]

PaulHoule 11y ago

It strikes me a lot like the way Google has tried out various sorts of VMs for Java in android.

simfoo 11y ago

Looking at MSDN and trying to find any setting about it in VS 2015, it seems .NET Native is only supported in Windows Store Apps. What about standard Winforms or Console Applications?

sandyarmstrong 11y ago
The end of the article says: "The current preview only supports Windows Store apps written in C# and running on x64 or ARM machines, but we’re hard at work adding support for other scenarios."

platz 11y ago

Compiles .NET/C# to native code using LLVM framework: https://github.com/xen2/SharpLang https://github.com/xen2/SharpLang