4 ms·

ngen isn't really an AOT compiler so much as an "ahead of just in time" compiler. You use it to run the JIT compiler and have Windows cache the output so that i

ngen isn't really an AOT compiler so much as an "ahead of just in time" compiler. You use it to run the JIT compiler and have Windows cache the output so that it can be reused instead of regenerated every time the program is run. Compared to a real AOT, it has several technical limitations, including: 1. You can't distribute native code. The usual workflow is that you deploy bytecode assemblies, and run ngen during installation to get the machine code into the local machine's native image cache. 2. You're still dealing with a two-phase compilation. This implications for what kinds of compiler optimizations are possible. 3. For the paranoid, having to still distribute bytecode means that your binaries are still easy to decompile. On the other hand, it also has some technical advantages. Generating machine code on the client machine makes more processor-specific optimizations possible, for example. And keeping JIT compilation in the loop means that you can still support features like Reflection.Emit().

eckyptang 14y ago
That's fair. Regarding your other points: 1. I don't want to distribute native code and I do run ngen during installation. I don't want an entire configuration and toolchain for each assembly and target platform (x86/x64/ARM RT/ARM WP/Silverlight) for example which we deploy one shared assembly to. It's hassle. The CLR is a virtual machine and one of the important things is that this problem goes away. 2. I would rather the compiler decides the optimisation for me. I really don't want to deal with that side of things. What I want is something that makes the problem go away which it does and let me deal with writing code rather than playing with compiler flags (I did a fair bit of VC++ and the CL.exe compiler optimisation options are crazy complicated). 3. I'm not too fussed about bytecode decompilation as most of our logic is server-side :)
- bunderbunder 14y ago
  Yeah, and for server-side I think ngen is the way to go - then you're really just looking for a way to shorten startup time, and that's perfect. But for something like mobile devices or video games, being able to do a real AOT compilation becomes a lot more interesting. You've only got one or two target platforms to worry about, which mitigates the concern about dealing with different build configurations. And you're dealing with an area that's more constrained in both space and speed, so there's more to be gained from some of the more tenacious optimizations that a C++-type compiler might do.
  - pjmlp 14y ago
    An example of the open positions Microsoft has for C# code compilation improvements https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=3&jid=88850&jlang=EN https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&#...

eckyptang 14y ago

That's fair. Regarding your other points: 1. I don't want to distribute native code and I do run ngen during installation. I don't want an entire configuration and toolchain for each assembly and target platform (x86/x64/ARM RT/ARM WP/Silverlight) for example which we deploy one shared assembly to. It's hassle. The CLR is a virtual machine and one of the important things is that this problem goes away. 2. I would rather the compiler decides the optimisation for me. I really don't want to deal with that side of things. What I want is something that makes the problem go away which it does and let me deal with writing code rather than playing with compiler flags (I did a fair bit of VC++ and the CL.exe compiler optimisation options are crazy complicated). 3. I'm not too fussed about bytecode decompilation as most of our logic is server-side :)

bunderbunder 14y ago
Yeah, and for server-side I think ngen is the way to go - then you're really just looking for a way to shorten startup time, and that's perfect. But for something like mobile devices or video games, being able to do a real AOT compilation becomes a lot more interesting. You've only got one or two target platforms to worry about, which mitigates the concern about dealing with different build configurations. And you're dealing with an area that's more constrained in both space and speed, so there's more to be gained from some of the more tenacious optimizations that a C++-type compiler might do.
- pjmlp 14y ago
  An example of the open positions Microsoft has for C# code compilation improvements https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=3&jid=88850&jlang=EN https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&#...