Hacker News Reader

Comment by Rohansi | Hacker News Reader

The article doesn't cover it but the GC being used by Unity also performs very poorly vs. .NET, and even vs. standalone Mono, because it is using the Boehm GC. Last I heard Unity has no plans to switch IL2CPP to a better GC [1].

It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP build.

[1] https://discussions.unity.com/t/coreclr-and-net-modernizatio...

View on HN

On the one hand, better GC is better but on the other, it doesn't matter all that much.

You tend to want zero per frame allocation as it is and that would probably not change.

As long as your less frequent garbage doesn't overtake the incremental GC, that's not really an issue either. If it's working incrementally as intended stutter shouldn't be an issue.

In a game there's no endless benefit from raw GC throughput like you might see on a server instance that could always push more requests per second.

The entire point of the incremental GC is to preserve frame latency budget at the expense of raw throughput. If you can guarantee <16ms frames, I'll work with whatever you can give me.

If your game is allocating so quickly that the incremental GC can't keep up, I would argue that solving this with a "faster" GC is just taking you further into hell.

> On the one hand, better GC is better but on the other, it doesn't matter all that much.

It shouldn't but it does. Boehm is a conservative GC so when it triggers it needs to scan a lot more memory for pointers than .NET's GC because it has to assume anything in memory could be a pointer.

> because it is using the Boehm GC

For what reason? Mono has a pretty good precise GC since many years.

Yes, SGen should be a lot better, but Unity cannot use it because they hold and pass raw pointers around everywhere. That's fine for Boehm but not possible with SGen. They're working on fixing this already but not sure why they aren't planning a move to a better GC.

Well, if they port to .NET (CoreCLR), that will move them to the MS GC.

Yes, but it also puts them in an awkward situation! They recommend (or even require, for some platforms) using IL2CPP for release builds which will still use Boehm GC and not run as quick as CoreCLR.

Do they still need IL2CPP if they have AOT? The goal was always to be able to have cross-platform native binaries right?

In theory yes, IL2CPP doesn't need to exist with modern .NET AOT support. In practice, per quotes in the article Unity may have a bit of a sunk cost issue and has no plans to support .NET AOT, only IL2CPP.

Some of that sunk cost may be the above mentioned pointer issue and not enough current plans for a smarter FFI interface between C++ and C#.

Unfortunately they do still need IL2CPP because Unity took a different direction than .NET: most reflection still works with IL2CPP but does not with .NET AOT. Switching would be a huge breaking change for everyone, including Unity.

Platform support is also still better with IL2CPP but .NET is catching up.

Re. the editor speedup, it should outright eliminate the "domain reload" thingy that happens because all of the C# needs to be unloaded and reloaded in response to a change.

Pretty sure that will still be there? It'll be different because CoreCLR doesn't really have AppDomains but it will still need to unload old assemblies and reload them all again. That's the only reliable way to reset everything into a clean state.

But only the assemblies that changed right? Or would it still be all of them?

No, for a full domain reload it reloads everything. This forces all static variables to reset, makes static constructors run again, etc.

AssemblyLoadContext.Unload https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

Reply on news.ycombinator.com