
Announcing .NET Native Preview - xyziemba
http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx
======
keithwarren
It seems the comments area here is full of lots of questions and few answers.
Let me try to clear some things up.

 _Lets start with how it currently works..._

When you create an application or website in C#,F#,VB.NET or any other .NET
language you are not really 'compiling' it per se to native code, you are
compiling it to an intermediate language called IL - very much like Java byte
code. When your application or website is run for the first time the .NET
runtime converts this code to native code on the local computer and then
caches this binary and officially compiled native version of your code. The
result is, the first time you run your app or a section of the code there is a
small performance hit while the .NET runtime converts your code to native. Let
me be perfectly clear, this is a one time thing - a first time thing. Once you
have gotten past that every subsequent run is going to be as fast as other
native code. (Why is it not as fast as something written in c or c++ you may
ask - because there are other things the .net runtime is providing for you
like garbage collection, but that is a whole other talk)

 _So how is this different?_

This preview allows you to skip this JIT process and image caching process
altogether. This is first targeted for Windows store apps, when you would
first run it on your machine it was slow on first launch because all this
extra work was being done. Microsoft decided they could take the server side
resources they had and run this JIT and imaging process ahead of time and when
someone downloads and installs your app - this work was already done and first
launch would be faster - as much as 60% faster. There are also lots of changes
under the hood to make this all work better - Andrew Pardoe is on this comment
thread further down and mentioned things like a refactored runtime, static-
optimized libraries, static marshalling all combining for performance wins.

 _Does this mean I can build apps for Unix with C#_

No, Mono is still the best way to do that

 _Can I build simple console apps with this and deploy to machines without the
.NET runtime?_

No, right now this is only available for Windows Store apps. Besides, unless
you have some Windows 98 machines sitting around nearly every PC has the .NET
runtime.

 _Will this make my app run faster?_

Starting up, yes. Normal operation, probably not. .NET runtime and jitter have
been around a long time and they are impressively efficient and fast. This
includes some tweaks to parts of the runtime but don't expect to see your text
file processing app go from 10 seconds to 2 or something like that.

 _Will this help me pick up chicks?_

Depends.

~~~
Patient0
How good/reliable is Mono on Linux now? If I knew _for sure_ that people are
actually using Mono on Linux robustly and with good performance I would ditch
the JVM - as a language/runtime .Net is so much better...

~~~
keithwarren
How good is Mono - Unity3D is based on it and I have not heard anyone complain
that the thousands of games built with it (including some of the most popular
ever on iOS and Android) are having performance issues because of the
underlying architecture.

~~~
felixgallo
Relative to the JVM, Mono on Linux is slow as heck.

------
modeless
So, uh, can I compile my C# app to an bare x64 .exe file, statically linked
with no runtime dependency on the .NET Framework, that will run on Windows 7
and 8? Or not?

Edit: This is a much better link: [http://msdn.microsoft.com/en-
US/vstudio/dn642499.aspx](http://msdn.microsoft.com/en-
US/vstudio/dn642499.aspx) Still not sure though, as they say "only Windows
Store apps can be created" which sounds suspiciously like "no".

~~~
jimmcslim
From the original link they say "Today's preview supports Windows Store
applications. We will continue to evolve and improve native compilation for
the range of .NET applications." which suggests to me that it might be on the
radar. However the scope of Windows desktop or server applications is
obviously much broader, so it might be a harder problem to solve there.

~~~
apardoe-MSFT
@jimmcslim Quite right, the smaller Windows Store profile is a more scoped
target. But everything is on the radar.

------
tdicola
I'm kind of scratching my head here, can someone explain what problem this
solves? There's already a CLR and already a way to build native apps for Win
8, etc. This is a new CLR that can run new 'native' apps?

~~~
plorkyeran
It gives faster startup time (due to AOT compilation rather than JIT), and
doesn't require that the .NET framework be installed. Possibly better runtime
performance, but I wouldn't expect huge gains there. P/Invoke should have
lower overhead, which may be highly relevant for some things.

I suspect that there's things that require this which they haven't announced
yet, since on its own it seems like something kinda nice but not beneficial
enough to justify creating.

~~~
tdicola
Yeah I don't understand the need to get rid of a .NET framework dependency
though. This only supports building Windows store apps, which only run on
devices that have the .NET framework right now...

~~~
itsboring
One admittedly crazy theory is that this is laying the groundwork for building
iOS apps and therefore would compete with Xamarin. Any kind of JIT would not
be allowed on the iOS app store.

~~~
tsenkov
The word is, that Microsoft is talking with Xamarin about a possible
acquisition.

------
DevKoala
What is the difference between this and NGEN? Anybody?

~~~
pantaloons
No MDIL. NGEN can still JIT for things like cross domain generics and because
it loads non-native code, still needs to optimize at run time.

Project N compiles to fully native code, so there can be no JIT, and
significantly smarter optimizations can happen since they don't impact
performance at runtime.

~~~
apardoe-MSFT
@Pantaloons: Right on all counts. One clarification: .NET Native and MDIL are
orthogonal. MDIL was used in Triton to split NGen into conceptually two
pieces: the optimized part (in the Windows Phone Store) and the part bound on
the customer's device to the installed Framework.

.NET Native produces completely native binaries. MDIL/Triton produces NGen
binaries that still need a runtime and, occasionally, a JIT.

~~~
shanselman
And Triton is...

~~~
apardoe-MSFT
Pay attention, Scott :)

Sorry. Triton is the Windows Phone 8 "Compiler in the Cloud". It basically
split NGen into two pieces, allowing the optimization to happen in the Store
while the .exe generation happened on the device. The interface between these
two halves is MDIL.

Bing will tell you a ton about Triton.

~~~
shanselman
Sorry, I see this in just one place. Sounds like an internal code name.
[https://www.google.com/search?q=Triton+.net+compiler](https://www.google.com/search?q=Triton+.net+compiler)

------
tsenkov
Was someone from marketing writing this: "the performance of C++ with the
productivity of C#" ... on startup. And not even on every startup, but only
the first. And not even the first, since, as you know, there already are a lot
of (unarguably, productive) features (such as GC etc.) making apps slower than
C++ apps.

Also, is it just me, but this sounds like a glorified NGen in the usual build
process (compiling for production goes straight to native), instead of NGen in
the background optimisation service?

I am all about getting the new tools, switching to new, more productive ways
of development (in fact I was programming in C# for about 3 years), I simply
hate when false information is being spread, just because it sounds better to
the sales person.

------
overgard
Do native apps still require a preinstalled CLR?

~~~
plorkyeran
No. Second entry in the FAQ ([http://msdn.microsoft.com/en-
US/vstudio/dn642499.aspx](http://msdn.microsoft.com/en-
US/vstudio/dn642499.aspx)).

~~~
overgard
Damn, that's awesome! For the longest time that was the only thing that really
bothered me about writing .NET code.

~~~
chc
But doesn't anyone with the Windows Store already have the CLR?

~~~
overgard
Probably -- I don't care too much about the windows store, I'm more excited
about being able to write C# code that doesn't require a VM. Not that there's
anything /wrong/ with the CLR, but one thing I miss about C++ when I'm not
writing it is self contained programs where it's just a small exe without a
bunch of huge dependencies.

~~~
moron4hire
I think you're forgetting about the Visual C++ 20xx Redistributables. They
aren't exactly tiny.
[https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG](https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG)

vs. the latest .NET install

[https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG](https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG)

This is a brand new Windows 8.1 computer.

~~~
modeless
The redistributable is huge but not required. You can statically link the C
runtime. That option has never been available for C#, and IMHO it's the single
biggest reason C# failed to replace C++ for Windows client development.

~~~
overgard
Exactly. The redist is potentially annoying, but for my own projects I tend to
statically link almost everything. It's not really a size thing, it's more of
a "I don't want to bug my potential users to have to install a bunch of system
altering things" viewpoint.

------
VexXtreme
So is this going to work on Linux?

------
ksec
There was GCJ that used to do this for Java. Sadly it has been discontinued.

It is interesting how every old is new again, we went from AOT to JIT and Back
to AOT again.

~~~
pjmlp
> There was GCJ that used to do this for Java. Sadly it has been discontinued.

There are lots of other AOT compilers for Java available.

> It is interesting how every old is new again, we went from AOT to JIT and
> Back to AOT again.

Yep, we already went through this as everyone founded out P-Code wasn't fast
enough. Then Anders Hejlsberg created Turbo Pascal.

------
rbanffy
It's interesting. It's more like a "static JIT" (BIT?) that does not account
for the different data characteristics the instructions will process (which is
something a JIT would/should do because it alters the actual program flow),
but I find the "fast from the start" idea very compelling. I wonder how long
will it take to Oracle (or the OpenJDK folks) to react to it.

------
mamcx
This could lead to a way to build a dynamic language on top of .NET and
eventually be usable in iOS? I ask because:
[http://docs.xamarin.com/guides/ios/advanced_topics/limitatio...](http://docs.xamarin.com/guides/ios/advanced_topics/limitations/)
aka: No Dynamic Code Generation

------
api
Only for Windows store? So who thinks walled gardens and feudalization are
coming to all desktop OSes in the next 5 years?

In the future, a store / certificate authority will be able to arbitrarily
revoke your right to run anything on your computer that isn't approved.

~~~
ksk
>In the future, a store / certificate authority will be able to arbitrarily
revoke your right to run anything on your computer that isn't approved

We're already there with Web Apps and other SaaS "innovative" technologies.

------
bananas
This is great. I hope they make this available for web apps because we've got
45 second warmup time and CPU spamming due to the massive size of the work the
JIT has to do when we deploy. Total pain.

I imagine this would help them keep costs down on Azure as well.

~~~
duncans
From my experience, much of an ASP.NET web app's start time is not so much the
JIT-ing but _before_ that, when the ASP.NET runtime compiles pages/views
(aspx/cshtml etc) into *.cs then DLLs. Pre-compiling can mitigate this.

Larger EF models can have quite an impact.

Also if you use New Relic, it can seriously affect startup time too.

~~~
bananas
Yes and no. We ship our views as content as we have a custom UI front end that
isn't razor or asp.net. The startup time for us is compiling NH proxies and
the fact that our bin dir is huge:

[http://imgur.com/EyjR5WH](http://imgur.com/EyjR5WH)

It takes forever for the JIT to actually compile all code paths in these
assemblies.

There's no PDBs in there either. Our domain and NH maps consume 42Mb of that
to give you an idea.

------
forgotAgain
Its truly a great thing. A single file deployment would be a tremendous
improvement. Also removing the ease with which distributed applications can be
decompiled helps as well.

Hopefully the marketing people let them spread it to all of their application
types.

------
Yuioup
No mention anywhere of ASP.NET. Is this going to help ASP.NET in any way?

~~~
detay
I asked the same question. Seems like they are just trying to get something
out of the mobile so far.

------
BuckRogers
So is this the mysterious 'M#' technology revealed?

~~~
CmonDev
That's a language, this is a compiler tech.

~~~
BuckRogers
That's already known. If you knew anything about 'M#' you'd realize these two
have to be related somehow. That's the question.

~~~
apardoe-MSFT
@BuckRogers, these two are related somehow. We've definitely benefitted from
conversations with the M# people and they've likely benefitted from
conversations with us. In fact, Joe Duffy once worked for our humble little
.NET team :)

------
detay
Microsoft: "We could speed up your server-side code, but instead we did speed
up the slow windows mobile apps that nobody cares about."

~~~
simplyinfinity
here, educate yourself

[http://msdn.microsoft.com/en-
us/library/6t9t5wcf(v=vs.110).a...](http://msdn.microsoft.com/en-
us/library/6t9t5wcf\(v=vs.110\).aspx)

~~~
detay
thanks, but no thanks. I won't go ngen just to speed up my start-up time on my
web applications.

[http://stackoverflow.com/questions/385841/does-it-help-to-
us...](http://stackoverflow.com/questions/385841/does-it-help-to-use-ngen)

