Hacker News Reader

Comment by frabert | Hacker News Reader

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.

View on HN

You 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

Thanks for the feedback! If you have some details and want to post them on 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++).

Couldn'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.

I couldn't, because exporting symbols that could be loaded from other apps was only possible with Native AOT

you 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

this 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

It’s isn’t about raw speed, but a consistent speed. JIT usually requires pausing the world to JIT. You don’t want that with audio.

disagree, an audio application (e.g. a livestream) will have audio changing at runtime, therefore, the critical hot and cold codepaths change at runtime, which a JIT will handle optimally with dynamic optimizations and deoptimizations. A statis PGO profile can and does help AOT by marking functions as cold and hot however a single profile is very weak/unsufficent against the general variety of runtime uses/inputs. Hence a JIT is much more usage resilient in its performance profile, aside from the initial (and pre-warmable) cold start.

Audio doesn't change in those applications in a way that would affect the profile. They're very math-heavy pipelines (if we're talking about vst-style effect stacking) where branching is avoided as much as realistically possible. What's in the studio stream itself is largely irrelevant.

You can disagree if you want to, but that doesn’t change the facts.

your disagreement doesn't change the fact AOT programs can become pathological by their a priori and not a posteriori tagging of hot and cold functions but hey free country, not assimilating valid arguments and being in denial is a human right. Also I realize you said "pausing the world", are you confusing JITs with GCs? Or enlighten me what in a JIT induce a stop the world pause besides a GC. As for this, it is hortogonal indeed, AOT java/C# still has a GC and has indeed SOTA submillisecond GC pauses with e.g. ZGC.

The fact is you don’t want unpredictable latency when processing audio. JIT produces unpredictable latency. This is a fact. You are saying that doesn’t matter, because in the end it is faster, but it totally misses the point about latency.

I have to say I am really appreciating the amount of conversation that arose here. My reading of this thread so far leaves me with:

> AOT may be bad for real time audio due to compile-time assumptions and other heuristics that are limited by the lack of run-time history.

> JIT is probably bad for real time audio, unless you take special precautions to pre-condition the execution context with a workload that approximate the live one.

How does this sound?

If you are doing anything realtime, it's also going to depend on your hardware as much as your software. The real answer, is it depends and it's all tradeoffs. There's no "right" answer, but generally, you want things to be predictable (something that AOT gets you), but if your performance budget gives you the ability to stop the world and JIT (because hardware), then that's ok too.

This sounds like we don't know how to sound.

loading memory from outside of L1 cache is enough to cause stutter in realtime audio

You could presumably JIT to a page, warm it up by running in a separate thread, then swap it in...

But for me, I'm not sure what gain that gives over AOT, and certainly adds background churn

it'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)

minecraft 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.

Unity 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_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 ;)

> 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-a... 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 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.

As for which is faster, I have a counter argument to your claims that JIT code runs faster than AOT compiled code for the same language.

C++/CLI is slower than normal C++.

Of course, sometimes JIT is faster. I remember gcj compiled code was plenty of times slower than code running under JVM.

I think there is no easy way to conclude which is faster, AOT or JIT.

Garbage collection also takes its toll. Looking at most benchmarks Go which is AOT compiled does not fare better than JIT-ed C# or Java.

For .NET I suspect there won't be much difference speedwise between AOT and JIT.

But AOT vs JIT has some other aspects. Like with Blazor who, at first, ran under a .NET virtual machine which ran under WebAssembly Virtual Machine. With AOT, things are simpler.

> C++/CLI is slower than normal C++

1) IIRC CLI is managed AKA garbage collected (BTW managed C++ is common practice e.g. chromium) 2) human resources, c++/cli has received much less optimization effort than LLVM/GCC/C#

as for Java https://github.com/oracle/graal/issues/1069#issuecomment-473... Go is the proof that GC-ed languages can be fast via AOT so it is not the discriminating factor. I suspect C++ with a GC is not much faster than JITed C# and the rest would be explained by other language brittleness such as e.g. the vtable hell, monomorphisation, etc Also weirdly, LLVM and GCC have received much more optimization human resources than openjdk and coreclr

> But AOT vs JIT has some other aspects. Like with Blazor who, at first, ran under a .NET virtual machine which ran under WebAssembly Virtual Machine. With AOT, things are simpler. well yes for this special case

> IIRC CLI is managed

CLI compiles to MSIL and runs on the CLR, so yes, very managed by default.

> c++/cli has received much less optimization effort than LLVM/GCC/C#

C++/CLI also found no regular users and people have been warned not to use it from even just months after its original release. From certain perspectives: It has really only had the one release in 17 years and been a "legacy tool" for most of that time.

(Possibly two releases if you count C++/CX, though that doesn't run on the CLR and is its own weird one-off thing for COM weirdness.)

Just like C++ and Objective-C were cheating when they came into the world, as C macro processors?

Are we using two weights here?

Reply on news.ycombinator.com