3 ms·

Ah it's from 2023, Miguel de Icaza : Swift Godot: Fixing the Multi-million dollar mistake: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/w

Ah it's from 2023, Miguel de Icaza : Swift Godot: Fixing the Multi-million dollar mistake: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo Highly recommend.

Rohansi 2mo ago
Can't say I totally agree with the claim that GC is a dealbreaker for games. There are trade-offs either way and games typically need to do things a bit differently to achieve high performance anyway. It is, however, a strong benefit of Godot over Unity because Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.
- pjmlp 2mo ago
  It isn't, some people managed to get quite rich with games written in GC languages. There is an agenda there, the business did not go down well with Unity for Xamarin, and now there is the whole Swift for Godot that needs to be sold for adoption. Unreal uses a GC for C++ code, yet the performance problem most people hit on Unreal is compiling shaders. Finally from academia point of view, reference counting is a GC algorithm, as any book worth reading in CS curriculum will have it as such.
- bob1029 2mo ago
  > Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future. How are we measuring "worst possible" here? Unity's GC is unique in that it has an incremental marking phase. The most important thing in a unity application is frame latency, not raw GC throughput. If you are generating so much garbage every frame that the incremental collector falls behind, that's probably on you.
  - needlesslygrim 2mo ago
    > Unity's GC is unique in that it has an incremental marking phase. Does ZGC not also have an incremental marking phase?
    - mibsl 2mo ago
      Also, the default collector, G1, introduced more than 15 years ago. Most JVM GCs are concurrent, too.
  - pjmlp 2mo ago
    A Jurassic GC introduced in Mono, that due to Unity not wanting to pay Xamarin for updates, meant it was mostly frozen in the days of Unity/Xamarin early collaboration. Unity preferred to go down the route of HPC#, Burst compiler and IL2CPP, and is still maybe one to two years to fully migrate to modern .NET. Meanwhile in Redmond, Mono is almost gone, with CoreCLR already in preview for mobile platforms, https://devblogs.microsoft.com/dotnet/dotnet-maui-moves-to-coreclr-in-dotnet-11/ https://devblogs.microsoft.com/dotnet/dotnet-maui-moves-to-c... Capcom's RE engine also uses their own fork CoreCLR, customised for consoles, Devil May Cry for PS 5 uses it.
    - Rohansi 2mo ago
      > Unity preferred to go down the route of HPC#, Burst compiler and IL2CPP, and is still maybe one to two years to fully migrate to modern .NET. They're replacing Mono with CoreCLR in Unity 7 which is Q1 2027. Somehow they're also doing this with no breaking changes too - even though they previously announced breaking changes due to the obvious differences between the two runtimes. Also, they have already said there are no plans to change the GC used by IL2CPP builds so it will keep using Boehm.
      - pjmlp 2mo ago
        Yeah, but will they deliver this time? Apparently the team has been affected multiple times during the various layoffs. Unity has been both a blessing for .NET adoption on the games industry, and also pain, given that many equate .NET with their Unity experience.
        Rohansi 2mo ago
        I have my doubts! I work on Rust (the video game) and we're excited to see how much better performance will be on CoreCLR. However, we were confused by the switch from "Mono replaced with CoreCLR with these breaking changes Unity 6.8" [1] to "Mono replaced with CoreCLR with no breaking changes in Unity 7 [2], with Unity 6.8 off the roadmap [3]". [1] https://discussions.unity.com/t/path-to-coreclr-2026-upgrade-guide/1714279 https://discussions.unity.com/t/path-to-coreclr-2026-upgrade... [2] https://unity.com/releases/unity-7 https://unity.com/releases/unity-7 [3] https://unity.com/roadmap https://unity.com/roadmap
  - Rohansi 2mo ago
    > How are we measuring "worst possible" here? The garbage collectors used by both .NET and Mono (since 2013) are precise, concurrent, and compacting. They know exactly what memory locations are GC references, scans them while the game is still running, and moves objects in memory to fix fragmentation. Pause times are kept short because heavy work is done on a background that. Unity's GC is conservative and incremental. It does not know what addresses are GC references so it has to scan everything that could be a GC reference. It's incremental which is nice but means you're expected to trade a few milliseconds of your frame budget for the GC to run. Being conservative means a chunk of your budget is spent scanning memory locations that aren't GC references. By default it uses the time spent waiting for vsync to run but not everyone plays with vsync enabled and lower spec systems have less room there so they end up running worse.

Ah it's from 2023, Miguel de Icaza : Swift Godot: Fixing the Multi-million dollar mistake: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo Highly recommend.

Rohansi 2mo ago

Can't say I totally agree with the claim that GC is a dealbreaker for games. There are trade-offs either way and games typically need to do things a bit differently to achieve high performance anyway. It is, however, a strong benefit of Godot over Unity because Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

pjmlp 2mo ago
It isn't, some people managed to get quite rich with games written in GC languages. There is an agenda there, the business did not go down well with Unity for Xamarin, and now there is the whole Swift for Godot that needs to be sold for adoption. Unreal uses a GC for C++ code, yet the performance problem most people hit on Unreal is compiling shaders. Finally from academia point of view, reference counting is a GC algorithm, as any book worth reading in CS curriculum will have it as such.
bob1029 2mo ago
> Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future. How are we measuring "worst possible" here? Unity's GC is unique in that it has an incremental marking phase. The most important thing in a unity application is frame latency, not raw GC throughput. If you are generating so much garbage every frame that the incremental collector falls behind, that's probably on you.
- needlesslygrim 2mo ago
  > Unity's GC is unique in that it has an incremental marking phase. Does ZGC not also have an incremental marking phase?
  - mibsl 2mo ago
    Also, the default collector, G1, introduced more than 15 years ago. Most JVM GCs are concurrent, too.
- pjmlp 2mo ago
  A Jurassic GC introduced in Mono, that due to Unity not wanting to pay Xamarin for updates, meant it was mostly frozen in the days of Unity/Xamarin early collaboration. Unity preferred to go down the route of HPC#, Burst compiler and IL2CPP, and is still maybe one to two years to fully migrate to modern .NET. Meanwhile in Redmond, Mono is almost gone, with CoreCLR already in preview for mobile platforms, https://devblogs.microsoft.com/dotnet/dotnet-maui-moves-to-coreclr-in-dotnet-11/ https://devblogs.microsoft.com/dotnet/dotnet-maui-moves-to-c... Capcom's RE engine also uses their own fork CoreCLR, customised for consoles, Devil May Cry for PS 5 uses it.
  - Rohansi 2mo ago
    > Unity preferred to go down the route of HPC#, Burst compiler and IL2CPP, and is still maybe one to two years to fully migrate to modern .NET. They're replacing Mono with CoreCLR in Unity 7 which is Q1 2027. Somehow they're also doing this with no breaking changes too - even though they previously announced breaking changes due to the obvious differences between the two runtimes. Also, they have already said there are no plans to change the GC used by IL2CPP builds so it will keep using Boehm.
    - pjmlp 2mo ago
      Yeah, but will they deliver this time? Apparently the team has been affected multiple times during the various layoffs. Unity has been both a blessing for .NET adoption on the games industry, and also pain, given that many equate .NET with their Unity experience.
      - Rohansi 2mo ago
        I have my doubts! I work on Rust (the video game) and we're excited to see how much better performance will be on CoreCLR. However, we were confused by the switch from "Mono replaced with CoreCLR with these breaking changes Unity 6.8" [1] to "Mono replaced with CoreCLR with no breaking changes in Unity 7 [2], with Unity 6.8 off the roadmap [3]". [1] https://discussions.unity.com/t/path-to-coreclr-2026-upgrade-guide/1714279 https://discussions.unity.com/t/path-to-coreclr-2026-upgrade... [2] https://unity.com/releases/unity-7 https://unity.com/releases/unity-7 [3] https://unity.com/roadmap https://unity.com/roadmap
- Rohansi 2mo ago
  > How are we measuring "worst possible" here? The garbage collectors used by both .NET and Mono (since 2013) are precise, concurrent, and compacting. They know exactly what memory locations are GC references, scans them while the game is still running, and moves objects in memory to fix fragmentation. Pause times are kept short because heavy work is done on a background that. Unity's GC is conservative and incremental. It does not know what addresses are GC references so it has to scan everything that could be a GC reference. It's incremental which is nice but means you're expected to trade a few milliseconds of your frame budget for the GC to run. Being conservative means a chunk of your budget is spent scanning memory locations that aren't GC references. By default it uses the time spent waiting for vsync to run but not everyone plays with vsync enabled and lower spec systems have less room there so they end up running worse.