Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing .NET Native Preview

blogs.msdn.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Announcing .NET Native Preview

#31

Post by 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.

Re: Announcing .NET Native Preview

#32

Post by [deleted] »

keithwarren wrote: post #31

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 websi…

[deleted]

Re: Announcing .NET Native Preview

#33

Post by apardoe-MSFT »

jimmcslim wrote: post #29
modeless wrote: post #16

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 Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".

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.

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

Re: Announcing .NET Native Preview

#34

Post by apardoe-MSFT »

itsboring wrote: post #5
spo81rty wrote: post #3

Earlier quoted context omitted.

CLR apps require just in time compiling which can take a little time to first run. So this should speed up opening the apps.

It seems like this is basically just the same thing that Mono has done for a long time with AOT. I'm not really sure how it differs from the Ngen tool, though.

.NET Native addresses many of the same issues as Mono AOT but it has a radically different basis. We had the advantage of hindsight :)

The biggest difference with NGen is the fact that .NET Native doesn't ever "fall back" to JIT compiled code. There are other differences--refactored runtime, static-optimized libraries, static marshalling, etc.--which can be seen by the perf wins over NGen. We're seeing 40% startup performance gain over NGen apps for top Windows Store apps.

Re: Announcing .NET Native Preview

#35

Post by apardoe-MSFT »

api wrote: post #17

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.

Today, Windows Store. Tomorrow, the world! :)

Re: Announcing .NET Native Preview

#36

Post by apardoe-MSFT »

pantaloons wrote: post #15
DevKoala wrote: post #6

What is the difference between this and NGEN? Anybody?

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.

@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.

Re: Announcing .NET Native Preview

#37

Post by swasheck »

keithwarren wrote: post #31

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 websi…

thank you for your lucid and erudite explanation.

will this help me pick up chicks?

as a dba, i appreciate your response, though i think that the answer is most likely, "probably not."

Re: Announcing .NET Native Preview

#38

Post by graycat »

keithwarren wrote: post #31

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 websi…

When I read the OP, I was tempted to scream about bad writing due to lack of context, undefined terminology, and general lack of explanation, not nearly the first time I was tempted to scream at Microsoft's technical writing abilities.

Your post provided essentially everything that was missing.

But, what the heck is a "Windows store app"?

What the heck is "jitter"?

Re: Announcing .NET Native Preview

#39

Post by overgard »

modeless wrote: post #28
moron4hire wrote: post #24

Earlier quoted context omitted.

I think you're forgetting about the Visual C++ 20xx Redistributables. They aren't exactly tiny. https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG vs. the latest .NET install https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG This is a brand new Windows 8.1 computer.

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.

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.

Re: Announcing .NET Native Preview

#40

Post by keithwarren »

graycat wrote: post #38
keithwarren wrote: post #31

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 websi…

When I read the OP, I was tempted to scream about bad writing due to lack of context, undefined terminology, and general lack of explanation, not nearly the first time I was tempted to scream at Microsoft's technical writing abilities. Your post provided essentially everything that was missing. But, what the heck is a "Windows store app"? What the heck is "jitter"?

Windows Store Apps are what was once called 'Metro' apps and now termed 'Modern' apps. They are essentially Microsoft's version of apps from iOS app store or Google Play store but focused on Windows 8 tablet and desktops (and as of today, the same apps you develop for these environments can also work on Windows Phone and XBOX One)

In the past if you were writing a client side or 'desktop' app for Windows you used C++ and MFC or a .NET language with Windows Forms or WPF (or lots of other options) to build that experience. Going forward Microsoft would prefer you build using this new model they are calling Windows Store apps. Along with that comes a set of rules and explicit declarations about what your app will do (much like we have on Android or iOS). This should in theory limit the number of crapware that exists, though that remains to be seen.

Jitter is a term we often use for a program that does the JIT work, JIT is an acronym for Just In Time which in context means Just In Time Compiler; it runs just before the code is needed. You have a program with 10K lines of code but the command you just sent the program only invokes 500 lines - a jitter or Just in time compiler will only convert the code that is actually needs to perform the operation you requested (thus performing faster).

Post reply on HN