4 ms·

> dotnet rely a lot on the JIT to optimize code .NET has had AoT compilation since v1. What, exactly, are you talking about? Sure, rely on JIT for stuff like

> dotnet rely a lot on the JIT to optimize code .NET has had AoT compilation since v1. What, exactly, are you talking about? Sure, rely on JIT for stuff like webapps and the like, but a CLI tool that is designed to run once would be a good candidate for AoT compilation, which, as I stated before, .NET supports.

anon_tor_12345 6y ago
What does AOT have to do with benchmarks that don't use AOT and report great performance? Also you're dramatically overstating how mature AOT is for dotnet https://github.com/dotnet/runtimelab/tree/feature/NativeAOT https://github.com/dotnet/runtimelab/tree/feature/NativeAOT >This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
- nvrspyx 6y ago
  I don't have much experience with .NET, but I believe the current production AOT option is the ReadyToRun publish option[1], which is actually a combination of AOT and JIT. The repo you linked is their work on a complete, native AOT implementation. [1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/ready-to-run https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...
  - anon_tor_12345 6y ago
    I'm getting downvoted but either people don't understand the difference between R2R and AOT (or they're just pissy today); from your link >R2R binaries improve startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. and >However, R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios and >Ahead-of-time generated code is not as highly optimized as code produced by the JIT. To address this issue, tiered compilation will replace commonly used ReadyToRun methods with JIT-generated methods.

4 ms·

> dotnet rely a lot on the JIT to optimize code .NET has had AoT compilation since v1. What, exactly, are you talking about? Sure, rely on JIT for stuff like

by holtalanm 6y ago

anon_tor_12345 6y ago
What does AOT have to do with benchmarks that don't use AOT and report great performance? Also you're dramatically overstating how mature AOT is for dotnet https://github.com/dotnet/runtimelab/tree/feature/NativeAOT https://github.com/dotnet/runtimelab/tree/feature/NativeAOT >This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
- nvrspyx 6y ago
  I don't have much experience with .NET, but I believe the current production AOT option is the ReadyToRun publish option[1], which is actually a combination of AOT and JIT. The repo you linked is their work on a complete, native AOT implementation. [1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/ready-to-run https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...
  - anon_tor_12345 6y ago
    I'm getting downvoted but either people don't understand the difference between R2R and AOT (or they're just pissy today); from your link >R2R binaries improve startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. and >However, R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios and >Ahead-of-time generated code is not as highly optimized as code produced by the JIT. To address this issue, tiered compilation will replace commonly used ReadyToRun methods with JIT-generated methods.