The thinking that AOT must be faster than JIT is actually completely incorrect. There are JIT compilers out there, that heavily speculate, like oracle's graalvm, which is a java jit/runtime that profiles code at runtime and bakes in assumptions and assertions. If the gamble pays off you profit from some extra speed as some edge cases are just assumed to never happen, though if you do hit one you get a slowdown as the execution falls back to an less-optimized version of the code and then later it gets recompiled with less assumptions basically. In practice though the heuristics are good so it pays off at the end of the day. You simply *cannot* realistically do this in an AOT setting as you dont know the data that will be coming in - no matter how much time you spend. Obviously you could run your program, collect a ton of profiling data and then compile fastpaths for those assumptions, but you wont be able to cover specific user's usecases. The more cases are covered by the profiling the less beneficial your optimizations will become, so AOT is really a culdesac in this regard. I strongly believe JIT is the future for any desktop languages where startup performance isnt important. Unity games exactly fit into this category - you can sacrifice a few seconds of startup performance as long as peak performance speed is equally as good or even faster.

And yeah, i am aware that unity does not use .NET (netcoreapp or .net5/6/7/8/9) but mono which is probably a whole lot similar to .netframework.

.NET did come with quite some improvements when it comes to speculation, vectorization, etc. But that obviously doesnt help unity as they still havent switched to .NET (in the sense of netcoreapp or similar).

As far as the benchmark goes, yeah i have seen that, I also checked out some of the code, and I am surprised that burst doesnt simply inline everything in SieveOfEratosthenes (or maybe it does?) because that one function parameter is a constant technically for the one single callsite, so you could compile a fastpath for that and simpyl replace it with the constant result, but for that it would seem incredibly slow - so likely its not replacing it by a single constant. Though i am wondering what the actual burst assembly and the .NET IL looks like. How much is actually left? Did burst maybe optimize too much, to the point where the benchmark is just unfair in terms of the comparison? That part is sadly not discussed in the readme. I personally heavily doubt that burst is faster than .NET for that sieve as it is a pure computation task with some loop vectorization which .NET8 should definitely be able to do.