[@ruantec]

During Channel 9 presentation it was revealed that C# is going to get full fledge DX12 support so everything can be developed with C# as well just as you do with C++ today without using SharpDX or SlimDX. The big question obviously was whatever is going to perform equaly and then.............


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

In case you don't understand what that means..... it basically gives C# the same performance and power of C++ while retaining C# great productivity.

Go native!

 

[makotech222]

Does this mean we can bring C# to other platforms? Linux, WinCE, Unity etc? Would mean a ton for me.

 

[@ruantec]

Does this mean we can bring C# to other platforms? Linux, WinCE, Unity etc? Would mean a ton for me.

C# already exist in those platforms and in fact it exist in a lot more ways people actually don't know. For instance C# code can be easily used to write iOS and Android apps using Xamarin and Mono is there for everything else. What this really means is that basically C# is getting the power it lacked to match C++ while retaining the great productivity without having the need of the JIT or the framework at all. During the "Build" conference MS has shown an incredible focus on C# specially with the announcement of support for DirectX12 which basically means that AAA games can be now developed with C# and the result is gonna be just as good as C++ but the main difference is that development time may be shorter. Another interesting point is MS mentioning XAML being made part of the DX engine system which is a great announcement since XAML is a huge part of modern application development and specially the awesome MVVM support.

The announcement of the Universal App system is also awesome as it means that any app written in C# can be compiled to run on Windows devices(including phones and the Xbox One) that use different architectures such as ARM or x86 while we can expect compilers for other plattforms from Mono and similar ones who will follow. Its probably too early to say this but i personally thought that MS wanted to kill .NET in the long run but i was wrong... with this move i just realized that they may actually kill C++(at least for Windows applications) as the current arguments used to write applications/games in C++ rather than C# will turn irrelevant after this move so i'm very excited.

C++ is incredibly awesome but it has some serious weakness in some areas where C# specially is very strong at. C# biggest dissadvantage was the overhead caused by the way it works in it's current form which even being greatly optimized can not reach some of the great optimizations a C++ application can have. All that may be possible in the future by using the upcoming native compiler. In it's preview form it targets the Modern UI of course but Desktop development is going to follow.

I've uploaded the original video which gives more information on the matter:

 

[makotech222]

Xamarin is expensive and mono isn't really up to date w.r.t c# 5.0. I wish you could just use .net on other platforms natively Unity really needs to get native c#

 

[DaMan]

So ngen on steroids. Will native binaries will ship sans CIL forever dooming us to x86/ARMv7? If only Visi ON had won.

 

[@ruantec]

Who said so? care to elaborate a bit more?

 

[resolutespider5]

Well according to that link it will result only in faster startup, and less memory usage. Not greater performance whilst running. Also limiting to Windows Store will mean Win 8+ only (on mainline Windows), although it should support xb1 and win phone.

Still it's got to be a good thing. Especially as MS have deprecated managed directx and xna, which this replaces.

So ngen on steroids. Will native binaries will ship sans CIL forever dooming us to x86/ARMv7? If only Visi ON had won.

I'd be very suprised if more than x86/ARM will ever be supported.

 

[@ruantec]

Not greater performance whilst running.

It's fact that native perform better mate but i will quote this instead to let others talk:

Microsoft .NET Native
.NET Native compiles C# to native machine code that performs like C++......

Link: http://msdn.microsoft.com/en-US/vstudio/dotnetnative

 

[@ruantec]

Here the announcement:
-------------------------------------------------------------------------------

We’re thrilled to announce the first release of .NET Native. Windows Store apps start up to 60% faster with .NET Native and have a much smaller memory footprint. Our first release is a Developer Preview that allows you to develop and test apps with this new compiler. This preview release of .NET Native offers you the performance of C++ with the productivity of C#. .NET Native enables the best of both worlds!

Download the .NET Native developer preview today and tell us what you think. This developer preview currently enables building apps for Windows Store on ARM and x64 architectures (stay tuned for x86.) .NET Native will soon enable a consistent and converged experience across devices. Today's preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications.

.NET Native continues to provide a first-class .NET developer experience in Visual Studio. You still get a great edit/compile/debug environment with productivity enhancers like Edit and Continue and code refactoring. You continue to upload MSIL app packages to the Windows Store. Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed.

.NET Native optimizes Store apps for device scenarios in all stages of compilation. We optimized the .NET Native runtime (a refactored and optimized CLR) to make apps start faster and consume less memory. The .NET Native compiler uses the world-class Microsoft VC++ optimizer back-end to make your app run faster. .NET Native libraries are refactored and optimized for Store apps. And .NET Native has the capability to link in library code your app uses into the app, allowing the optimizer to work globally across your app’s code and library code. In the end, your app is optimized for your user’s device, whatever platform, architecture, OS or form factor it might be running. The end result –apps just get faster!

Some of the most popular Windows Store apps on Surface devices are already running on .NET Native. This includes applications such as Wordament and Fresh Paint, which are seeing multi-second startup wins.

Tune into the //BUILD conference for more details. Also, check out the Going Deep Channel 9 Video on .NET Native.

Getting started with .NET Native
The .NET Native developer preview installs on top of Visual Studio 2013 Update 2 RC.

Compiling with the .NET Native Toolchain
After your project is loaded, you can enable the .NET Native compiler. Make sure you’ve configured your app to compile for a specific architecture, x64 or ARM. .NET Native compiles to native code, so you need to target a real machine type instead of Any CPU. There are a few ways to do this—in the Solution Property Pages:



Or in the handy dropdowns at the top of the editor window:



Once you’ve selected a supported machine type you’re ready to enable your project for .NET Native compilation. Right-click on the project name and you’ll see the “Enable for .NET Native” option has appeared. (OK, it was always there, but if you selected it without selecting x64 or ARM you’d get an error.)



Selecting this actually causes a few things to happen. First, it creates a new file for your project called “default.rd.xml”. This file contains runtime directives that help the .NET Native compiler understand what metadata and type information needs to be preserved in order for your app to run correctly, so things like reflection mostly just work, even though you are statically compiling everything!



Second, selecting “Enable for .NET Native” builds your app. Visual Studio will also run a static analysis tool on your app to give a quick read on whether you are using any feature that’s not yet in the preview release. This will generate a “.NET Native Code Generation Compatibility Report” that will pop up with information about your app. Also, you can always rerun the static analysis from your project’s context menu.

If your app is like most Store apps, you’ll see this in the Compatibility Report, meaning you’re ready to test your app thoroughly with .NET Native.



If your app uses many complicated patterns or yet to be implemented features (e.g., WCF), you might instead get some workarounds and guidance. We’ll dive into each and every topic but for now if you run into any issues, please send us feedback, either in the .NET Native forum or by emailing us directly at [email protected].

We look forward to hearing from you! Get the new VS Update, download the .NET Native Tools, start making your apps faster and tell us what you think!

 

[resolutespider5]

It's fact that native perform better mate but i will quote this instead to let others talk:
Link: http://msdn.microsoft.com/en-US/vstudio/dotnetnative

But at http://msdn.microsoft.com/en-US/vstudio/dotnetnative it says:

.NET Native compiles C# to native machine code that performs like C++. You will continue to benefit from the productivity and familiarity of the .NET Framework with the great performance of native code. Popular Windows Store apps start up to 60% faster and use 15-20% less memory when compiled with .NET Native.

Only mentions faster startup and less memory usage. Still these are all good things, and they'll optimize things further I expect, so there will probably be other improvements.

 

[@ruantec]

Just by saying that performs like C++ they are already mentioning performance mate. C# is incredibly fast in it's current form and it has tons of optimizations as well which really performs excellent in many key scenarios. However when it comes to performance C++ always had the lead as compiled code will always be faster not to mention it has a great compiler with optimizations and all that stuff now can apply to C# as well.

http://codemyroad.wordpress.com/2013/06/20/native-code-vs-managed-code-performance-and-development/

 

[resolutespider5]

Well I read "performs like c++" to mean they're both compiled to native code! But it all sounds good anyway.

 

[makotech222]

And now they open source Roslyn. Effin sweet. Just hoping for an opensourced runtime

 

[resolutespider5]

And now they open source Roslyn. Effin sweet. Just hoping for an opensourced runtime

Well if you think about it Mono is an opensourced runtime. The Mono CLR performs JIT compliation of .net code. I can't see why Mono can't do something similar to .net native really.

All .net native really does is it switches from JIT compilation to complilation before the app is shipped.

 

[DaMan]

I'd be very suprised if more than x86/ARM will ever be supported.

I like to dream. .NET was our ticket to freedom. Excluding the NDK apps Android will soon have ARMv7/ARMv8/x86/x86-64 apps and the user will be able to AOT compile them with ART.

 

[-Ashe-]

Just by saying that performs like C++ they are already mentioning performance mate. C# is incredibly fast in it's current form and it has tons of optimizations as well which really performs excellent in many key scenarios. However when it comes to performance C++ always had the lead as compiled code will always be faster not to mention it has a great compiler with optimizations and all that stuff now can apply to C# as well.

http://codemyroad.wordpress.com/2013/06/20/native-code-vs-managed-code-performance-and-development/

Actually you're reading a bit too much into it. It's not like .NET is interpreted at this point, it already gets JIT-ed to native code before it gets executed. You're just removing that let's-recompile-before-we-execute-it part, which explains the start time improvement they mention. But at the same time you're losing the portability, since a native x86 build obviously won't work on an ARM machine, so you'll end up with 2 builds instead of 1.

You may also want to consider why languages like Java and C# are slower than C++, even when directly compiled to native code: all the memory allocations and garbage collection, reflection, etc, obviously reduce performance and require more memory.

A native compile ahead of time (vs JIT) can actually reduce overall performance: when you generate the native code at build time, you don't know what type of machine the end user will have: Intel, AMD, which instruction set, etc. When you compile on the user's machine, you get that information and can generate something that's actually more optimized (and could easily end up faster than a generic native C++ build, if written properly).

 

[@ruantec]

I know those facts i was trying to give a simple answer to resolutespider5. Of course you will have to compile different builds for different platforms but you will be able to optimize a lot of things as well making better applications for specific scenarios. The way it works right now is that you have the option to activate the .Net Native compiler so for now you will be able to write applications just as you did till now or use the native compiler if desired.

 

[-Ashe-]

but you will be able to optimize a lot of things as well making better applications for specific scenarios

That's the thing... you won't... you'll just do the JIT ahead of time.

 

[@ruantec]

Well, let's wait and see how is gonna turn out... i haven't tested myself but will do in the coming days.

 

[resolutespider5]

That's the thing... you won't... you'll just do the JIT ahead of time.

Well they are only claiming a faster startup (no JIT compilation), plus less memory usage (a JIT compiler wont need to be loaded). I think "compiles C# to native machine code that performs like C++" means basically that both C# and C++ are compiled to machine code, which then performs at the speed of machine code, not that .net native C# and Win32 C++ will have the same speed.

But if MS focuses their attention on .net native, and deprecates JIT .net, then all there attention will be directed towards optimising .net native. So this could definitely lead to other performance gains. And of course a faster startup is desirable, all that JIT comilation takes time. And on machines with low memory not having a loaded JIT compiler could help performance.