Next Generation Emulation banner

.NET goes NATIVE!!!!!!

6K views 29 replies 8 participants last post by  @ruantec 
#1 · (Edited)
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!
 
See less See more
#2 ·
Does this mean we can bring C# to other platforms? Linux, WinCE, Unity etc? Would mean a ton for me.
 
#3 · (Edited)
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:
 
#4 ·
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 :p Unity really needs to get native c#
 
#7 ·
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.



I'd be very suprised if more than x86/ARM will ever be supported.
 
#9 ·
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 dotnetnative@microsoft.com.

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!
 
#11 ·
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/
 
#16 ·
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).
 
#13 ·
And now they open source Roslyn. Effin sweet. Just hoping for an opensourced runtime :)
 
#14 ·
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.
 
#17 ·
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.
 
#22 ·
This is not a replacement for the already dead XNA. MonoGame actually continue XNA legacy and is being developed constantly this days. However as the MS BUILD conference shows DX12 will have support for C# if i understood right and this technology is going to allow the same. In other words you could go forward and do whatever you want. Talking of which this lead me to an inevitable question..... what's the future of C++ if this get developed forward?

C++ holds the golden standard and is being widely used around the world because it offers ways to do things you can't do on other technologies that easy. However there are tons of companies out there that would use C# instead because of it's beauty, fast development and great productivity but because they have no other chance they still use C++. I've worked for several companies myself that would gladly switch and even the one i work right now would love to switch. The problem however is that some tasks won't work as good as they expect them to be if the actual .net was used.

Still... there is a special case were we work with vector graphics that now use WPF using a wrapper i wrote. I've demostrated that a good written application in C# can perform excellent and things may change in the future if this continues like this. There is still a long way to go but this is some exciting news for all those who actually love C# and probably the start of a nightmare for those who never expected this change.
 
#23 ·
People mocked me regularly for developing primarily in C# & VB.NET years ago. Now, everyone seems to realize just how excellent the .NET framework really is and everyone's a C# aficionado. Funny how that works.

(not speaking of anybody here)

Back on topic, this is very cool news. The few .NET naysayers will have nothing left once .NET = .NET native... err, natively. :p
 
#24 · (Edited)
People mocked me regularly for developing primarily in C# & VB.NET years ago. Now, everyone seems to realize just how excellent the .NET framework really is and everyone's a C# aficionado. Funny how that works.

(not speaking of anybody here).
Not only you but that was my case too. The main reason is that a lot of developers out there didn't properly used C# and even worse they started completely wrong. Also most of the points and issues against .Net were based on older versions that no longer apply to newer versions of the framework which is pretty fast and solid. We also have the Ryu Jit this days and a hell bunch of posibilities that were not available in the past. Because of that the awesomeness and great posibilities of the framework were overseen but thanks God time proved how great it is.

I mentioned on my last post a project at work that was simply impossible to achieve with C++(at least for the timespan we got). I finished the project 3 days ago and showed how fast and great a properly written WPF/C# application can be and they are extremely happy. So happy that nobody ever says something against .Net anymore and everyone is willed to learn it and use it in our future projects. In most cases my project while having a bigger amount of vector graphics is up to 3 times faster than the C++ simplistic version not to mention smoother. As a comparison about 1 and half year ago mentioning .Net was like insulting most of devs at work as all they thought was ".Net is so slow" but ironically never trying it out themselves but basing there words in a old project that was badly written like 5 years ago.

I wrote a wrapper to allow interaction between C++ and C# via MVVM as well as a MVVM core and few C++ classes that makes it easy to work with both languages. Right now we continue the work in C++ but more and more parts are getting .Net implementation and in the future there are plans to fully replace everything necessary.

Back on topic, this is very cool news. The few .NET naysayers will have nothing left once .NET = .NET native... err, natively. :p
Basically there is absolutely nothing left once is added to the desktop version of the framework which should come in the near future.
 
#25 ·
Indeed c#/.net is so much more productive and safer to use than C++. I worked at a C++ embedded device place, and the software was terrible. Hanging pointers/null pointers everywhere, terrible architecture, etc.. Now i'm working at a .net 4.0 place, and its so much more fun to code, and so much cleaner too. I'm learning WPF and MVVM on my free time and it has such a deep learning curve, but it looks so much nicer than Winforms.
 
  • Like
Reactions: cooliscool
#26 ·
Yeah, C++ has it's use tho. and most specially when dealing with hardware and other stuff like we do at my workplace but it shows it's age and the syntax is overrated in comparison to the clean architecture C# has when written properly.

As for MVVM and WPF... make sure to check my WPF/MVVM tutorial i posted here a while ago. It's far from perfect and i've found ways to improve it further so i will probably write an update in the future. MVVM and WPF has a lot of advantages over Winforms and if you use it properly your applications will work faster because you will save a lot of search, casting and other things you usually need in a Winforms application. The reason is quite simple and that's because you will execute the code exactly where its needed and you will mostly have all the info you have at the right place while having a clean architecture.

The idea is forget about controls and events tied to a certain UI element but focus on your logic and the way you do things. This not just increase the posibilities but make your application far more flexible and dynamic without requiring silly and dirty tricks.
 
#28 · (Edited)
This isn't about porting active-x controls from IE but far beyond that. The idea is to be able to natively compile .Net code using the same Compiler as C++ while having the same amount of optimizations and Speeds as well as retaining .Net Features and advantages. In other words what this does is turn a language like C# into the new C++.
 
#30 ·
They clearly said that they will look into that in the future but for now they are focusing in store apps. However, with Windows 10 and desktop store apps support as well as universal full trusted app you pretty much have desktop support for .net native in another way.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top