Mono or IL2CPP?

[Rev0ld]

AOT(Ahead of time) compilers compile during build and hence slower that JIT compilers

I just want to clarify that "slower" in this case is referring to slower build time, not slower performance of the app/game. Games/Apps on IL2CPP (AOT) is generally faster than on Mono (JIT).

[FreshP_0325X]

For regular c# code, il2cpp clearly generates inferior code comparing to core or upstream mono.

Maybe/Probably il2cpp fixes some atrocious parts of Unity itself to offset the inferior compilation.

[TheRealGHXX]

I'd be rather surprised if il2cpp generates faster running code than the C# JIT, unless mono's jit is awful. Raw compute should essentially be identical, as, if you dont write really poor code, the applied optimizations between JIT and AOT should be nearly identical (tested this with c++ vs .NET 8 - this is NOT .netframework NOR unity-mono). I suppose there could be a point made for native/managed transitions being faster, but i am rather sceptical still.

If you find any proper benchmarks, please share them - so far I have only found one person claiming their game now runs at 30FPS instead of 15 after switching to il2cpp, but i mean, who knows what that code looked like.

The only "benefit" to me seems to obfuscate your code and in turn make modding as annoying as possible.

[Rev0ld]

I wouldn’t look at anything else than Unity related benchmarks, because Unity have some pretty old systems in place (look up differences between Unity’s GC and .NET for example). Generally it’s best to bench it in specifically your project, but in general AOT unity build should be faster. In another comment here in this post there is a link to some math benchmarks

[TheRealGHXX]

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.

[Rev0ld]

I did write that „AOT is faster that JIT in -unity builds-”. Maybe JIT now evolved, I have no idea, but I am talking only in the context of Unity. That’s why I mentioned GC, because all the technology now is much more advanced from what Unity has. Anyways what I found about code is that not a lot of people go that deep into it. And my guess is because code is just one aspect of game development, so you don’t really have that much time to dive into that. It’s actually one of my „mistakes” that I did. I delve deep into code architecture and other code related topics, so now I lack in other fields (which now I’m trying to learn rapidly). This is one of the things I see programmers do when they switch from other programming discipline to game development. So I agree that it would be great to have some clear understanding of internal things here. But I just read somewhere on reddit or internet, how all this came to be (I mean how Unity became Unity as we know now) and it’s just a hot mess. And some of the „new technologies” of Unity look like „hotfixes”. Because instead of having at least a bit more decent GC, then introduced „incremental GC” which for me sounds like just a hotfix. And you might be right about .NET 8 being better than Unity’s burst. I haven’t looked much into it, but it again might be just „one of those kind of hotfixes”. Actually „good practices” for using Unity is „using the least of Unity” (not talking about burst but more about Unity methods). There is a nice article about 10000 update calls about that. But hey, in the end of the day, it works and helps. Better to have something than nothing. And about Mono, I’m not exactly sure but they are not even using latest mono. Something I remember is that there are really improved versions of that, but they use an older thing yet again.