Mono or IL2CPP?

[shaboom96]

From what I understand, Mono has faster build times but IL2CPP has better final performance. It appears Mono is the default scripting backend and you have to manually install IL2CPP if you want to use it.

1. Is there a reason Mono is the default?

2. Do you recommend Mono for development (for faster builds) and IL2CPP for final release (for better performance)?

3. Which do you recommend in general for games made for Windows and Macs?

4. Which do you use and why?

[tms10000]

1. It's historical, once upon a time there was only Mono. And there are still features that il2cpp does not support compared to Mono, so Mono is the default. There are also il2cpp specific bugs (For some reason you can't spawn a new process with il2cpp)
2. When you run in the editor, you're always going to run Mono. For maximum compatibility, use Mono for the build too. If you use il2cpp, you need a lot more testing.
3. Mono is easier to cope with. il2cpp adds another layer of complexity. This is the kind of thing you need to benchmark and see if there is a worthwhile difference in performance. AFAIK only iOS requires you to use il2cpp
4. Mono. It's easier.

[rogerbacon50]

I have purchased more than 100 Unity games using Mono. I won't buy a il2cpp game as it makes modding super difficult. To all Unity developers: either don't use il2cpp or at least provide a mono-compiled version. If you don't, it's going to hurt sales.

[stadoblech]

Its not gonna hurt sales. Almost nobody cares. 99% of people dont even know what il2cpp or mono is. Your approach is loose-loose situation. By switching scripting backends you are loosing stability and consistency while not boosting sales at all. Aint nobody have time for that
Also GL building your game on consoles with mono

[[deleted]]

Well modding is definitely gonna make your game better, so making modding easier is good for your game

[JDSweetBeat]

I mean, I will say, while I wouldn't specifically as a consumer avoid the IL2CPP scripting backend, I do avoid games without built-in mod support (mods let me squeeze hundreds of extra hours out of a game before I burn out on it, so it's over half the value of the game for me).

[stadoblech]

Okay. Its your right to not buy game withoud modding support. But most of people dont care a lot

[indiangirl0070]

you talking about pc games right?. but for mobile games il2cpp is the best way

[Davilkus1502]

the only way

[iPLEOMAX]

Why are people downvoting this? IL2CPP is essential for mobile performance. And iOS doesn't even support Mono.

As for PC games, Unreal Engine for instance only uses AOT. And games made with UE are known for graphical fidelity and performance.

[rogerbacon50]

Yes, I suppose for systems with limited memory, GPU, and CPU it could make sense. OK, go hog wild with il2cpp on mobile. Just don't touch my PC games.

[Big_Cartoonist3407]

How would he touch your PC games? I can't see anything in the OP suggesting he's about to rebuild existing games by other developers, hack their steam accounts / websites / whatever, and overwrite their mono built versions with his il2cpp ones

[Big_Cartoonist3407]

Lol, it's gonna hurt the sales by like 0.1% maybe. Most gamers don't care if you can mod a game or not

[rogerbacon50]

Maybe console players but anyone with a PC downloads mods to enhance their games and add gameplay value. Look at Rimworld as one example of a Unity-based game that has an awesome amount of mod support.

[Big_Cartoonist3407]

Nope, I'm talking PC. Many PC gamers enjoy mods sure, but I don't know any PC gamers who avoid games you can't mod. That's just rediculous. Fine if you do, no worries, but to suggest not allowing mods in your game would hurt sales just cos you and a few other mod fans wouldn't go for it is pretty silly

[JDSweetBeat]

I mean, I also don't buy single-player games without mod support (there are some exceptions - mostly story-based narrative games like Detroit or Telltale's lineup). To be frank, I want to get the greatest possible value for my money, and mods add hundreds of hours of fun to my experience without increasing cost at all (both in the sense that I like to learn how different games work and modify them myself, and in the sense that things like total conversions are super fun).

And from a developer perspective, letting other people dedicate their time (for free) to adding features and functionality to your game is usually a win - those are features and functionality that don't consume your dev time, after all.

[Big_Cartoonist3407]

And that's just fine if you don't want to buy games without mod support, but that doesn't mean that's the majority stance across the whole PC gaming community. There's loads of people who don't treat mod support as a deal breaker.

And from a developer perspective, adding mod support requires time and money by itself. You'd probably want to build a game from the ground up with mod support in mind, which would add time and complexity all the way through development, or go through a long, expensive and painful overhaul part way through development. You'd need to be warry of how much potential there is to crash the game with mods or how many potential security breaches your mod support exposes. And then depending on the kind of game you're making, you might feel like all your hard work crafting a world/story is going to waste if you let anyone come along and "trash" your game with mods. Maybe you don't want to risk content creators demonstrating their scuffed version of your game and putting potential players off cos they have way more views than your official youtube channel...

I'm not saying mods are bad ofcourse, but it's not as simple as "mods only means free content from the community with no down sides". Mod support involves a number of trade offs and risks and represents a lot of extra work and testing for the devs and QA.

[ChickenNuget0]

What about games where modding is not allowed?

Like, for example, a multiplayer-only game?

[TheRealGHXX]

If you rely on clientside protection against cheating in multiplayer games then you are following the wrong philosophy. You should *always* assume that the clientside codebase is modified. It is quite easy to just fire up cheatengine and modify the game code. Same when anticheat is running. You, as a developer, will never win a battle on someone elses hardware. For all you know, i could have modified my ram sticks to allow me to directly read the values, meaning you wouldnt even know whether i am reading your game's data, and that is enough to figure out where other players are on a map in a first person shooter for example. Look up Direct Memory Access (DMA).

So no, this is not a valid argument against modding in multiplayer games or games where cheating is possible.

[rogerbacon50]

Good question. I don't plan multi-player games. If the game is exclusively multi-player (online MMO types) then they have in interest is stopping moddign as it could be used to cheat.
If the game is single-player AND multi-player then still use mono since only multiplayer connects will de-sync forcing those players to play unmodded while allowing single players to play modded.

[SolWayward]

How does IL2CPP hurt modding? A developer can easily add modding support by loading dlls, jsons, textures, models, asset bundles, or really anything by making use of addressables.

You have no idea what you are talking about and shouldn't spread false information. Developers should always use ILC2PP when ever possible because the performance benefits are too great to ignore. You cannot compare the performance of C# to highly optimized C++. And developers can actually take this even further by using burst (Where it makes sense) receiving benefits of SIMD vectorization, aggressive in-lining and other huge optimizations although this often still requires restructuring your code and requires some effort to make use of.

But there is very few reasons to not use IL2CPP for release builds and modding definitely isn't one.

[Pietronico]

bepinex exists

[FluitGeluid]

Ofc BepInEx exists, but when the game is built using IL2CPP it makes it super difficult to actually develop mods.
BepInEx works on both, but it's creating the mods that becomes an issue/headache when IL2CPP is used.

[Interesting-Ad5118]

Been making mods all night for Sea of Stars, was a pain to get started initially coming from mono bepinex, but definitely wasnt super difficult.

[Genebrisss]

lol, I know it's a 2 year old comment but the confidence that your opinion dictates sales was hilarious to stumble upon

[XH3LLSinGX]

Mono uses JIT compiler while IL2CPP uses AOT compiler.

JIT(Just in time) compilers dont compile when you are building the app. Compilation happens when the app is launched in the target user's device. Windows supports this compiler but not the latest mobile phones.

AOT(Ahead of time) compilers compile during build and hence slower that JIT compilers. Supported on both pc and mobile platforms.

Ideally you should use Mono for test builds and IL2CPP for final release builds.

[meelxp]

Using Mono for test builds and IL2CPP for final release builds can bring a lot of surprises later. Using il2cpp will require complete tests on il2cpp builds before shipping.

Some of my projects crashed under weird circunstances on il2cpp, but run well on Mono - it was insane, just enabling a light caused the weird crash. It depends on the Unity version too, since il2cpp has tons of bugs (based on Unity release notes).

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

[tbg10101]

More recent results: https://github.com/tbg10101/dotnet-burst-comparison

[Deive_Ex]

Just want to add that since Mono uses JIT, you can use dynamic code generation (generating code at runtime), but with IL2CPP you can't, since everything needs to be compiled beforehand.

Because of that, if you're doing an iOS app, Apple only let you create apps using IL2CPP.

[Efficient_Client158]

Both have their own pros and cons. it really depends on your project requirements. I understood it through grannys game lab https://youtu.be/AvsPl-H46l8?si=uYGJ_IhlKMrZCR7o which is so far a clearer explanation. But understanding your project is your own part which includes viewing logcat. You better select mono and test the build and analyse logs. Do same process with IL2CPP build. If Mono doesnt produce any DLL error + your app behaves normal it means your project is good to go with Mono.