Native AOT Overview
ericsink.com
ericsink.com
When I saw that .NET 7 included AOT, I immediately downloaded it to play around. It's clearly not fully baked (missing macOS support), but what is there is great. AOT makes C# a direct competitor to Go for projects that don't need to wring every last cycle out of the CPU, and it doesn't have the same squeamishness about language complexity that characterizes Go.
The only part of .NET 7 that really bothers me is the compilation process. I couldn't find any compile-to-obj command with flags and such, instead there's a `dotnet` command that takes its input via a monolithic `.csproj` XML file and spits out a fully-formed binary. Trying to integrate C# into a Unix-style build pipeline (make/Bazel) doesn't seem straightforward in the current SDK.
If they don't fix this by version 8 I might have to build my own CLR apphost solution :(
> When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder.
https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
and then maybe even change the default build to always use AOT and you're precisely where golang is
I mostly use Visual Studio but I think in practice you're supposed to compile whole .dll's or assemblies all at once, which acts as the unit of compilation; I don't think the csharp compiler generates native object-files-for-every-.cs or translation unit, the kind of approach you'd expect from javac or g++. Someone please correct me if I'm wrong though! I'd like to learn more if there's a more granular/incremental unit of compilation.
Since Roslyn and the compiler itself are mostly a library, maybe you could also write your own custom "csc-for-bazel" compiler or something to sort of bootstrap the whole thing and offer tighter integration...
.NET 8 will support Native AOT on macOS, I think.
https://learn.microsoft.com/en-us/dotnet/standard/assembly/r...
I’ve been thinking a lot about what a good intervention of .NET and tools like Buck would look like. I think both Buck 1 and Bazel’s rules_dotnet directly target the csc compiler. Given how much logic is written in MSBuild files and how many steps are part of the build (analyzers, illink, ilcompiler), I think it makes sense to target the dotnet executable directly. Having a way to set arbitrary MSBuild properties and items would be nice.
It would be nice if you could generate Visual Studio projects from the Buck targets.
Lastly, it would be nice if these rules supported Bazel-style persistent workers. Both MSBuild and csc support a client server architecture, but rules_dotnet does not take advantage of that currently. Performance suffers accordingly.
At the same time, it's obvious that that's a considerable chunk of work.
Also, IDEs like VS and VS Code are reliant on MSBuild APIs to construct a semantic understanding of the projects, so without MSBuild files, they won't properly function.
This is an unfortunate problem, which I don't have a simple solution for.
Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.
Mono included a powerful GUI framework which run on far more platforms than the .NET GUI. And Ximian/Xamarin invested a lot of effort to be as compatible as possible to all aspects of .NET (see e.g. https://www.mono-project.com/docs/about-mono/compatibility/).
It was also not explicitly intended, blessed or even recognized by MS for a number of years. It was just another open source project.
This gave rise to other platforms that were attempting to improve on C (GNOME) / C++ (KDE), such as D, and finally JavaScript for GNOME. Meanwhile, web apps (and then Electron apps) became de-facto defaults due to their cross-platform nature.
Had MS embraced (err...in a positive way!) Mono from the start, taking into consideration Miguel's influence in the GNOME community, GNOME 3 might have been written in .NET.
Anyway, I'm not sure what Mono's AOT compiler looks like these days, but the new Native AOT for .NET (which is improved in .NET 8) is definitely designed for production and things like binary size and startup speed, with no external dependencies, and they definitely seem to be trying to make it act and feel like other natively compiled AOT languages. People care more about it these days because a big shift is in things like containerized runtimes where you don't want to pay for the overhead of distributing the .NET runtime for each container, because they can't be shared. So things like AOT, dead code elimination, reflection removal for source generators at build time etc all add up. Cold-start time is also important for some of those uses.
Linux distro fragmentation and userspace ABI compatibility being an afterthought also makes some FOSS/Linux projects that require interpreters/runtimes more annoying than they need to be and that also had some cultural, perceptive ramifications for a long time too -- that's not really .NET specific, but it probably never helped. Like, you're saying "just download an executable and run it" but that was actually often not workable in many cases for many reasons for many apps. And whether or not whether users understand what those reasons were, correctly or not, it colors their perception of that class of tools.
But anyway. These days there are lots of solutions for these problems. Native AOT is a pretty welcome solution for a good class of issues IMO, and Mono and .NET Core both seem to be established in various domains. I'll definitely be looking forward to trying Native AOT on server-side apps.
> Banshee is a pretty long-lived project; we might be talking 10+ years ago.
Mono was a very different thing back then -- less mature, and Microsoft (mid Ballmer era) seemed to have a love/hate relationship with it.
It was announced for Java 6, half baked during Sun/Oracle transition, and to this day most people still don't grasp the difference between OpenJDK, other OpenJDK distributions and alternative JVM implementations.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
There's clearly something else underneath, the <LinkerArg> element is exactly what I would want to generate when running link.exe, but most of the configuration options are wrapped in a layer of gunk.
Ideally it would be possible to invoke a command directly to convert a bunch of *.cs files into a .dll (or .a), then I could use existing logic to link it with link.exe (or ld).
And C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.DotNet.ILCompiler\build\Microsoft.NETCore.Native.Unix.targets (where the linker is selected)
See the area around and after this chunk
<CustomLinkerArg Include=""$(NativeObject)"" />
<CustomLinkerArg Include="-o "$(NativeBinary)"" Condition="'$(TargetOS)' != 'windows'" />
<CustomLinkerArg Include="/OUT:"$(NativeBinary)"" Condition="'$(TargetOS)' == 'windows'" />
<CustomLinkerArg Include="/DEF:"$(ExportsFile)"" Condition="'$(TargetOS)' == 'windows' and $(ExportsFile) != ''" />
<CustomLinkerArg Include="/LIBPATH:"%(AdditionalNativeLibraryDirectories.Identity)"" Condition="'$(TargetOS)' == 'windows' and '@(AdditionalNativeLibraryDirectories->Count())' > 0" />
<CustomLinkerArg Include="-exported_symbols_list "$(ExportsFile)"" Condition="'$(TargetOS)' == 'OSX' and $(ExportsFile) != ''" />
<CustomLinkerArg Include="-Wl,--version-script=$(ExportsFile)" Condition="'$(TargetOS)' != 'windows' and '$(TargetOS)' != 'OSX' and $(ExportsFile) != ''" />
<CustomLinkerArg Condition="Exists('$(_Win32ResFile)')" Include=""$(_Win32ResFile)"" />
<CustomLinkerArg Include="@(LinkerArg)" />And some really good stuff came out of the Mono as well. Like Mono.Cecil
Basically, don't do that. "dotnet build" invokes "msbuild" which is a build system analogous to make. If you want a remotely peaceful life, just lay out the project the way Microsoft expect you to and let it do its thing.
You can invoke Roslyn "csc" from the command line, but some of the more obscure bits of tooling (e.g. building "self contained" executables) are only implemented as .dlls that are msbuild Task objects.
Msbuild isn't too bad once you've got over the culture shock that (a) everything is XML rather than tab-delimited makefiles and (b) you've got a glossary of terms that maps to things you know https://learn.microsoft.com/en-us/visualstudio/msbuild/msbui... and (c) you get the binary log viewer https://msbuildlog.com/, which is a fantastic tool that gives you total observability of every detail of the build process. Of which there is a lot.
Separate thought: .net AOT is still very much experimental. All sorts of things are silently incompatible with it, either in the "refuses to build" or the "crash at runtime" way. I'd only use it for small projects built from the ground up to be AOT.
The idea of trying to learn some new ecosystem-specific build tool (in this case msbuild) is unappealing. Done that too many times, and I'm tired of fighting with tools written for/by people who think projects are written in a single language.
[0] I hear Buck2 is a step in this direction.
I looked briefly at Buck2 but it doesn’t work yet (for my purposes, at least). Facebook have copied the old Google cliche, “you can use the old version that’s deprecated, or the new version that doesn’t work yet”.
Edit to add: a million times yes to your general point! Language-specific build systems are bad.
I've only had to interact with it for C[++], but based on that, I'd do a lot to not use it for projects I work on. No-action-needed builds are orders of magnitude slower than with any other tool, the determination of what needs to be rebuilt is ... not accurate, understanding the build rules is hard, there is very little useful documentation, there are a lot of bugs.
It's certainly true that most things aren't AOT-compatible out of the box -- this is basically due to the heavy ecosystem reliance on reflection.
BUT, it definitely shouldn't be silently incompatible. We've spent a lot of time building "trimming warnings" (https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...) that should flag any and all incompatibilities.
If there's some incompatibility, a warning should be generated. If there isn't that's likely a bug on us (https://github.com/dotnet/runtime). But conversely, if there are no warnings, you should be guaranteed that the app should be AOT-compatible.
Now we all use unbelievably locked-down mobile devices, nobody even knows what files and folders are, and fewer kids than ever are able to learn about how computers work by messing around under the hood. Other amazing things are happening, but it's sad what gets lost.
Hope you're doing well Sandy, been a long time.
dotnet publish /property:PublishSingleFile=true --configuration=Release --self-contained=trueOther than that, it seems that due to other languages, there is misconception that Native AOT is a panacea that is superior in all areas to normal single-file executables that use JIT. In fact, on average, JIT produces faster code because some optimizations are only possible with tiered and dynamic PGO compilation.
What Native AOT offers is very small binaries, with very fast startup, and smaller working set. It can also be integrated as a standalone static/shared library into a different application.
Self-contained apps don't require AOT compatibility and may have higher peak throughput (as you said, JITing can be faster in some cases).
It's up to you and your application whether the trade-offs make sense.
FYI I'm the lead of the Native AOT team at MSFT.
The key thing about .NET AOT is that it compiles the whole framework together, so right now the `dotnet` command is the top-level tool that connects all the pieces together. If you wanted to integrate with other native code, you can use `dotnet` to output a static library, which could then be linked with the rest of your native code.
You're right that this can be complicated to integrate with other build tooling. It's something we can work on, but there's a bit of inherent friction around the .NET side, where it needs to find all the appropriate libraries, NuGet packages, etc, and a make/bazel world.
Definitely something we can work on as we go forward.
Most of the buzz about .NET Native AOT is focused on things like startup time for compiled executables in cloud environments. For good reason.
But Native AOT also supports compilation to libraries with a C ABI, including both shared libs and static. My blog series tends to lean in that direction, talking about interoperability.
Some of the posts talk about very fundamental things. Some of the later posts give mention to a (somewhat experimental) binding generator I've been working on, using CLR metadata to automatically create glue and projections for other languages like Rust and TypeScript.
In general, interop between C# and other languages has been possible for a long time, but Native AOT allows it to be done without hosting a CLR, and as the feature matures, I think that'll make it more interesting for some use cases.
I assume running an app in a container wouldn't allow you to sidestep that problem?
Still it's not practically usable and that's what counts for me. From what I understand it is plagued with the same issues as the C# AOT when it comes to reflection and therefore serialization. There is a whole list of other issues as well[1].
I think some of this issues can never be solved by the compiler alone but need to be addressed in the ecosystem. It would be important, for example, that the most common and important libraries dispense with reflection to play well with AOT.
Finally GraalVM is just a single project with its own specific agenda. If Oracle changes its mind about these goals tomorrow Java AOT will be dead once again.
These are the reasons I'm still not optimistic about Java AOT, even if GraslVM is really cool project.
[1] https://www.graalvm.org/22.0/reference-manual/native-image/L...
Even if I have no direct need for AOT I’m eager for the added type safety and sanity gained by getting rid of reflection, not least for serialisers!
Also Android Java uses a mix of JIT and AOT, depending on the workloads.
Hardly dead.
Well-written libraries that do not use reflection to generate new code in runtime do not require any changes and "just work". A lot of new code shipped is now written with Native AOT in mind to be compatible (with some exceptions, looking at you, SemanticKernel).
But I've made some progress with Avalonia.
Here's a sample using Native AOT and Avalonia, with a projection to Rust:
https://github.com/sourcegear/bridge-info/tree/main/samples/...
And here's (basically) the same sample projected to TypeScript:
https://github.com/sourcegear/bridge-info/tree/main/samples/...
These are built using the binding generator I mentioned elsewhere in the comments here. All this stuff is just raw tech, not a ready-to-use solution.
With a newish .NET they don't need reflection for AOT code, as JSON libraries can use source generators instead.
For schema serialization on known types, there are codegen tools (i.e. moc for MessagePack): https://github.com/neuecc/MessagePack-CSharp
MessagePack is migrating to Rosalyn code generators, so basically invisible codegen. Cysharp's newer serialization library, MessagePack, already uses this: https://github.com/Cysharp/MemoryPack
This does not address pre-existing packages obviously. To make them work with AOT you might need to include an XML file (rd.xml) that indicates all the types that could be dynamically generated in your code. It is quite brittle and AFAIK everything might work until you get a runtime failure if something you did not include ends up being constructed.
I've stopped using AOT, as IMO it's not (currently) suitable for complex, real-world apps - unless you are prepared for a lot of testing and pain.
2000s Compile to binary > bytecode (performance, size and startup time important)
2010s Compile to bytecode > binary (performance important)
2020s Compile to binary > bytecode (size and startup time important).
There are also several optimizations that can be made in AOT compiled code that are not allowed when you enable unrestricted reflection or dynamically loading code. As an example, suppose an interface is implemented by just one type in your code. If you AOT compile it, the compiler can safely assume that all calls to methods on that interface actually go to that single type implementing it, thus it can replace interface dispatches with direct calls.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
So, while it was released as a non-experimental feature, actually it still is.