6 ms·
Native AOT is a great concept, I was hoping to use it to build VSTs and other kinds of music plugins without having to deal with C++, since the binaries it prod
by frabert 4y ago
Native AOT is a great concept, I was hoping to use it to build VSTs and other kinds of music plugins without having to deal with C++, since the binaries it produces can export symbols.
The stopper I found was the abysmal debugging support, I hope that has improved in the meantime.
- andygocke 4y agoThanks for the feedback! If you have some details and want to post them on https://github.com/dotnet/runtime https://github.com/dotnet/runtime, we can include them in planning. As you might have guessed, this is a pretty huge long-term project and many things basically need to be rebuilt from scratch in order to be supported. Debugging is one area where the form factor will likely demand different behavior vs. JIT, so it will be an evolving scenario. It would be great to know what you would expect vs. what you saw, and importantly what you expect to be different from a traditional native debugging experience (like in C++).
- bob1029 4y agoCouldn't you test plug-ins with JIT? Seems like only some minor performance caveats would apply. Tiered compilation would kick in on hot paths after a while.
- Shadonototra 4y agoyou don't want any slowdown introduced by a JIT compiler when you deal with audio you want consistent perf, AOT makes more sense over there Unity game devs for example had to fight with the mono JIT by warming up their gameplay code otherwise it'd introduce micro stutters
- SemanticStrengh 4y agothis is a myth, AOT is generally slower than JIT for high level languages. Yes though prewarming is underused and important see e.g. https://github.com/facebook/nailgun https://github.com/facebook/nailgun
- Shadonototra 4y agoit's not a myth, it is a well documented overhead do a google search a audio VST, a game, a CLI are not servers where JIT makes more sense (sometimes)
- SemanticStrengh 4y agominecraft is not faster on GraalVM AOT nor will be every Unity Game out there. C++ is faster but not because it is AOT, it's because it is a lower level language which is more brittle and less permissive/dynamic. AOT on high level languages reduce throughput for most uses, even with PGO.
- Shadonototra 4y agoUnity games now ship with IL2CPP, to benefit from AOT compilation, the language and its constructs remains the same, gone are the stutters people were experiencing Minecraft was rewritten in C++ to increase performance on lower end devices and overall general performance (no longer need to warmup JVM to remove the stutters during gameplay, lower downtime for restarts in realm based servers) https://old.reddit.com/r/Minecraft/comments/i27zzo/5_ways_the_slow_minecraft_problem_can_be_fixed/ https://old.reddit.com/r/Minecraft/comments/i27zzo/5_ways_th... We can talk all day about high/low level languages, JIT/GC introduce overhead, that's it When you only have 8ms for your framebudget at 120hz, every bit make the difference The rest is handled on the GPU anyways, AOT compiled ;)
- SemanticStrengh 4y ago> Unity games now ship with IL2CPP, to benefit from AOT compilation No that is cheating, IL2CPP is a C# to C++ transpiler.. Which is similar to writing a C++ program, interesting technology though. However it's true Unity also has a Burst compiler which is AOT is release mode and output LLVM IR. Look that is interesting and that is exactly where I wanted the conversation to go. GraalVM is generally slower on AOT than on JIT. I expect the same from .NET 7 AOT (haven't checked but is likely true) Unity Burst is interesting because it leverage an infrastructure that has received an enormous number of human resources and optimizations for AOT (LLVM). However Unity does not allow to benchmark Burst vs modern .NET JIT so it's very possible that Burst is in many cases slower than .NET JIT. This can't be verified easily and I'm not aware if Burst can be used outside of Unity but I guess one could write the same microbenchmark for both, it's just that no-one did it. However, Unity has gained a lot of technical debt because its own tooling (and Mono) are stuck on .NET 4.x They are apparently actively seeking to update their support and will leverage CoreCLR to some extent so maybe once it will be done, comparisons will become easier and they might or not replace Burst by regular CoreCLR, time will tell. https://forum.unity.com/threads/gdc-2022-the-future-of-net-and-unity.1255956/ https://forum.unity.com/threads/gdc-2022-the-future-of-net-a... https://forum.unity.com/threads/net-6-support.1059992/ https://forum.unity.com/threads/net-6-support.1059992/ > Minecraft was rewritten in C++ C++ is faster because it is lower level, my point is Minecraft do not use Java AOT. and as said many of minecraft stutters are avoidable GC pauses. It's true 8ms is a tight budget indeed hence why ZGC is a key advance, a place where C# is currently inferior to java. > The rest is handled on the GPU anyways, AOT compiled Haha nice try, I appreciate the tentative but I'm not sure you're being right. regarding the topic of compiling shaders for a 2D GUI, using a JIT is a key advantage, see e.g. https://github.com/blend2d/blend2d https://github.com/blend2d/blend2d As for GPU drivers (handling openGL/etc) I think its a mix of both but I have forgotten the things I had read about them on phoronix Most game emulators strongly benefit from JITs shaders too.
- frabert 4y agoI couldn't, because exporting symbols that could be loaded from other apps was only possible with Native AOT
- kant2002 4y agoYou generally do not want use NativeAOT for plugins, since you can have just one .Net runtime inside process. If somebody will write another plugin you will have a problem or experience very strange things