I think we have a few .NET-familiar devs on here at least. I wanted to know what you thought about .NET Native. If you aren't super familiar with it, the best outline of it is located here.
Please do not jump to conclusions on the subject unless you really do understand how it works. I've found that many I try to discuss this with who know regular .NET have no clue how .NET Native works and then jump to incorrect conclusions based upon false assumptions. If you would like to learn the details, I suggest:
Video 1: https://www.youtube.com/watch?v=JoE7OytQWj0
Video 2: https://channel9.msdn.com/Shows/G...de-Compiler-in-the-Cloud-and-MDIL
That out of the way, this is how I see it:
1. The grand benefit of .NET in general is obviously to make it "nicer"/make applications both easier to develop for businesses, supposedly cutting down development time, and also perhaps compatible with a wider array of machines.
2. The above is certainly at the cost of performance and control. However, many business tasks can get by using the .NET model because they do not necessarily require high-performance computing.
3. However, in the grand scheme of things, it makes me wonder about Microsoft in that they essentially started with native, went to abstraction/GC land, now are actually coming back to native again. I say "coming back" because now all Windows Store Apps use .NET Native, so it's clear that MS is shifting in this direction. That said, the GC is definitely still there, but it's just a part of the compiled native binary rather than being in a separate runtime.
But watching that first video of them taking C# code, turning it into CIL (MSIL), then tree-shaking, transforming, turning that into MDIL, then feeding that into the Visual C++ back-end, then taking the output and running it thru a binder (linker, basically) to produce a .exe and dll... I can't help but think "what on earth are these guys doing???"
So the .NET framework has now become like a jQuery of sorts... Just a giant statically-linked library which is attached to executable files, adding overhead, but supporting a standard format. Microsoft seems to be attempting to overcome the challenges of native, such as lack of cross-compatibility between architectures, by dynamically making decisions in the cloud and then shipping and linking when the user downloads/purchases the app. Essentially, you program your code in Microsoft's proprietary markup, send them that, and then they inject their framework and eventually send the consumer a native binary.
My questions are:
1. Do you think Microsoft is actually doing something innovative here or are they running in circles?
2. Would you consider using .NET Native for your development needs? Why or why not?
Please do not jump to conclusions on the subject unless you really do understand how it works. I've found that many I try to discuss this with who know regular .NET have no clue how .NET Native works and then jump to incorrect conclusions based upon false assumptions. If you would like to learn the details, I suggest:
Video 1: https://www.youtube.com/watch?v=JoE7OytQWj0
Video 2: https://channel9.msdn.com/Shows/G...de-Compiler-in-the-Cloud-and-MDIL
That out of the way, this is how I see it:
1. The grand benefit of .NET in general is obviously to make it "nicer"/make applications both easier to develop for businesses, supposedly cutting down development time, and also perhaps compatible with a wider array of machines.
2. The above is certainly at the cost of performance and control. However, many business tasks can get by using the .NET model because they do not necessarily require high-performance computing.
3. However, in the grand scheme of things, it makes me wonder about Microsoft in that they essentially started with native, went to abstraction/GC land, now are actually coming back to native again. I say "coming back" because now all Windows Store Apps use .NET Native, so it's clear that MS is shifting in this direction. That said, the GC is definitely still there, but it's just a part of the compiled native binary rather than being in a separate runtime.
But watching that first video of them taking C# code, turning it into CIL (MSIL), then tree-shaking, transforming, turning that into MDIL, then feeding that into the Visual C++ back-end, then taking the output and running it thru a binder (linker, basically) to produce a .exe and dll... I can't help but think "what on earth are these guys doing???"
So the .NET framework has now become like a jQuery of sorts... Just a giant statically-linked library which is attached to executable files, adding overhead, but supporting a standard format. Microsoft seems to be attempting to overcome the challenges of native, such as lack of cross-compatibility between architectures, by dynamically making decisions in the cloud and then shipping and linking when the user downloads/purchases the app. Essentially, you program your code in Microsoft's proprietary markup, send them that, and then they inject their framework and eventually send the consumer a native binary.
My questions are:
1. Do you think Microsoft is actually doing something innovative here or are they running in circles?
2. Would you consider using .NET Native for your development needs? Why or why not?
Edited by Todd
on
1. Yes and no.
Yes, because there's little point of jitting same binary code over and over again. Just do it once and use it. So this is right approach that should be standard and part of MS .NET at least 15 years ago.
No, because this has been done by mono for something like 10 years already. Officially they do this on iOS and similar platforms that doesn't allow jitting at runtime (PS, Xbox). Unofficially you could use that with mono if you manually called right functions. I was doing this in ~2008 or 2009. Basically I developed with C# in VS. And then I used mono to do AoT and used native binaries as application executable.
2. No. Because too "Microsofty". It supports Store applications only, and really - who cares about them. And no idea what they will decide to break, limit or otherwise remove functionality in future as MS usually does. If I need to write .NET code now I will ship it as .NET app. If I really need to get native code out of it, I'll use Mono AoT functionality that doesn't limit me.
At one point I was actually writing my own IL to native llvm IL generator app (and llvm IL got compiled to native machine code). Got to the point where I could run simple single threaded applications just fine, including linking with pinvoke'd code. But then I lost interest in this project.
Yes, because there's little point of jitting same binary code over and over again. Just do it once and use it. So this is right approach that should be standard and part of MS .NET at least 15 years ago.
No, because this has been done by mono for something like 10 years already. Officially they do this on iOS and similar platforms that doesn't allow jitting at runtime (PS, Xbox). Unofficially you could use that with mono if you manually called right functions. I was doing this in ~2008 or 2009. Basically I developed with C# in VS. And then I used mono to do AoT and used native binaries as application executable.
2. No. Because too "Microsofty". It supports Store applications only, and really - who cares about them. And no idea what they will decide to break, limit or otherwise remove functionality in future as MS usually does. If I need to write .NET code now I will ship it as .NET app. If I really need to get native code out of it, I'll use Mono AoT functionality that doesn't limit me.
At one point I was actually writing my own IL to native llvm IL generator app (and llvm IL got compiled to native machine code). Got to the point where I could run simple single threaded applications just fine, including linking with pinvoke'd code. But then I lost interest in this project.
Edited by Mārtiņš Možeiko
on
Todd
But watching that first video of them taking C# code, turning it into CIL (MSIL), then tree-shaking, transforming, turning that into MDIL, then feeding that into the Visual C++ back-end, then taking the output and running it thru a binder (linker, basically) to produce a .exe and dll... I can't help but think "what on earth are these guys doing???"
Iphone happened. Smartphones & tablets happened. ARM happened.
I'm sure there were handful of "oh-shit" moments as it slowly sank in that the Free Lunch is over and all these large C# codebases have to run on low-powered mobile devices now.
On that end, .NET Native improves cold startup times by around 60% (according to MS).
I feel that's the main benefit. And that matters on low-powered mobile devices.
Does it actually significantly increase run-time performance? ... Doubtful.
The core programming model of C# is just incompatible with "high-performance" code. Too little control over data layout, too many indirections and too many heap allocations pointing all over the heap leading to many cache-misses.
That being said, C# runs more than fast enough for any game I'd want to make.
I care deeply about iteration times, rather than the game startup times alone.
Since iteration times with .NET Native AOT toolchain are significantly longer - than just plain C# compiler + JIT, I won't be using it.
It's something than can be used as a final step before shipping, but I doubt it's worth the time investment.
Edited by pragmatic_hero
on
There are some potential benefits that an AOT compiler could bring:
auto vectorization
smarter array bounds elision
smarter devirtualization
I don't know if the current AOT compilers do this to any decent degree though. The current JITs don't do any auto vectorization at all, array bounds elision is pretty basic, and devirtualization has just started getting introduced. You would *sometimes* get big speedups from auto vectorization. If you had a compiler as clever as the intel C compiler this might even happen semi-regularly.
auto vectorization
smarter array bounds elision
smarter devirtualization
I don't know if the current AOT compilers do this to any decent degree though. The current JITs don't do any auto vectorization at all, array bounds elision is pretty basic, and devirtualization has just started getting introduced. You would *sometimes* get big speedups from auto vectorization. If you had a compiler as clever as the intel C compiler this might even happen semi-regularly.
Edited by Jack Mott
on
mmozeiko
There is absolutely no reason why JITs couldn't do the same things.
Exactly, the only difference between AOT and JIT is how much time you have until the result must be ready.
That creates tradeoffs with how much you can optimize but not to the level of eliminating some classes of them entirely