
.NET Native Performance - Artemis2
http://blogs.msdn.com/b/dotnet/archive/2014/04/24/dotnetnative-performance.aspx
======
velox_io
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
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.

------
Lx1oG-AWb6h_ZG0
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?

~~~
runfaster2000
.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-
live...](http://www.zdnet.com/article/microsoft-codename-redhawk-lives-in-
windows-8/)). 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...](http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-
net-framework-4-6.aspx#ryujit).

~~~
MichaelGG
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
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...](http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native-deep-
dive-dynamic-features-in-static-code.aspx). 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.

~~~
sixbrx
I'm late to this conversation, but thanks for this information. I'm still
trying to understand the role of the source language in AOT compiling - is it
actually looking at the source language and not the IL bytecode? If so, is
that because IL is too low level or something similar, it would prefer to work
at AST level?

~~~
MichaelGG
I wrote to them and asked. Their response is:

"...we only support C# and VB in a technical sense. You've picked up on one
reason why[1]; we do IL scanning and rewriting and look for various patterns."

They do use the normal, unmodified csc compiler to generate the IL[2]. But it
sounds like they are partially decompiling the IL to get C#-level semantics?
There's also this comment[3] regarding expression trees:

"the JIT runtime does emit those as dynamic code, but .NET Native can
interpret those"

So I'm guessing they have to look through your source and figure out when you
exec one and then do it head of time? I'm not sure how that can be a general
solution, as you can construct arbitrary expression trees at runtime, even
using external input. Maybe that part doesn't work, but normal programs don't
do that?

I do wish they were a bit more open and clear on all this. (And wow, the
public messaging is really confusing other developers. I've had a customer
come super excited because .NET Native would obviously cut his server
requirements by a nice chunk... had to explain it wouldn't work at all in his
scenario.)

1: I wrote asking "Are dependencies being taken on specific quirks of the C#
compiler? Like, I dunno, how certain members are named, or the way C# creates
Expression Trees"

2: [http://blogs.msdn.com/b/dotnet/archive/2014/05/09/the-net-
na...](http://blogs.msdn.com/b/dotnet/archive/2014/05/09/the-net-native-tool-
chain.aspx)

3: [http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-
native...](http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native-deep-
dive-dynamic-features-in-static-code.aspx)

------
simfoo
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
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."

------
joshuapants
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?

~~~
mhomde
All Windows (Phone) 10 apps will per default be compiled with .Net Native

~~~
PaulHoule
Are there going to be any Windows Phone 10 phones given that Microsoft is
pulling out of phones?

~~~
mhomde
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
> 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!

------
platz
Compiles .NET/C# to native code using LLVM framework:
[https://github.com/xen2/SharpLang](https://github.com/xen2/SharpLang)

------
CmonDev
_> "Pay-for-Play Reflection"_

Native _and_ allowing reflection? I am now much less interested in M#.

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

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

