3 ms·

There is one already - it's called ngen.exe and it shipped with v1.0 of the framework. http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.80%29.aspx http:

There is one already - it's called ngen.exe and it shipped with v1.0 of the framework. http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.80%2...

pjmlp 14y ago
Thanks for letting a .NET developer that was part of .NET Beta Partners program know about NGEN. I meant a way to convert the application to binary that you can distribute without having a CLR VM installed.
- eckyptang 14y ago
  The OS usually ships with it or it can be bootstrapped easily. I don't see the problem. We deploy 4.0 framework with our desktop software as well. ClickOnce takes care of the installation with the package manifest. Github also do that with their GitHub for Windows app.
  - pjmlp 14y ago
    Usually standalone compilers have more ways to optimize. Maybe it would be enough to make NGEN more configurable, on the other hand I am yet to check the 4.5 improvements.
    - eckyptang 14y ago
      I'm not sure I want to tune stuff constantly myself. Ngen is unchanged in 4.5. There were a few big changes in 4.0.
      - pjmlp 14y ago
        Microsoft says otherwise, http://msdn.microsoft.com/en-us/magazine/hh882452.aspx http://msdn.microsoft.com/en-us/magazine/hh882452.aspx I just have not had yet the opportunity to research this myself.
        eckyptang 14y ago
        Thanks for posting that - genuinely didn't see that :)
bunderbunder 14y ago
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

Thanks for letting a .NET developer that was part of .NET Beta Partners program know about NGEN. I meant a way to convert the application to binary that you can distribute without having a CLR VM installed.

eckyptang 14y ago
The OS usually ships with it or it can be bootstrapped easily. I don't see the problem. We deploy 4.0 framework with our desktop software as well. ClickOnce takes care of the installation with the package manifest. Github also do that with their GitHub for Windows app.
- pjmlp 14y ago
  Usually standalone compilers have more ways to optimize. Maybe it would be enough to make NGEN more configurable, on the other hand I am yet to check the 4.5 improvements.
  - eckyptang 14y ago
    I'm not sure I want to tune stuff constantly myself. Ngen is unchanged in 4.5. There were a few big changes in 4.0.
    - pjmlp 14y ago
      Microsoft says otherwise, http://msdn.microsoft.com/en-us/magazine/hh882452.aspx http://msdn.microsoft.com/en-us/magazine/hh882452.aspx I just have not had yet the opportunity to research this myself.
      - eckyptang 14y ago
        Thanks for posting that - genuinely didn't see that :)

bunderbunder 14y ago

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.