12 ms·

As a fulltime Unity dev, this doesn't matter much to me, because it doesn't address the major pain point for larger Unity games. This .NET upgrade does not incl

by psyc 9y ago

As a fulltime Unity dev, this doesn't matter much to me, because it doesn't address the major pain point for larger Unity games. This .NET upgrade does not include a modern garbage collector, and the garbage collector update has been "maybe next year, but definitely not now, because it's hard" for as long as I've been using Unity. Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#. I've considered switching to Unreal, but that has GC built into it a little too much. I know nothing about its characteristics, but it makes me wary. This thread makes me want to investigate Godot. Can anyone provide a one-sentence summary of the GC situation there?

robrtsql 9y ago
Sure! Hopefully a more experienced Godot dev will jump in and correct me if I'm wrong here.. Godot uses reference counting, but additionally supports a function which you can call on an object which will cause it to become 'unmanaged' by the reference counter, allowing you to free its memory on your own terms (or leak the memory, if you're not careful). Godot 3.0 added support for Mono, but I'm not sure how that works. I'm guessing that game objects in Godot are still reference counted, but now you also have memory allocated by the Mono runtime which will be garbage collected.
- AlexAndThunder 9y ago
  From: http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html http://docs.godotengine.org/en/3.0/getting_started/scripting... ' Memory management If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref function is provided for creating weak references. '
  - jeremiep 9y ago
    Reference counting is a form of garbage collection. And depending on your usage patterns it might not even be the fastest one. Lots of increments/decrements on the refcount interleaved in normal code can kill the gains over a traditional GC that has nearly free allocation, batched finalizations and doesn't pollute the instruction stream with increments/decrements. Also with a traditional GC you pay nothing if you don't allocate memory; the collector will never run. You still pay the full price of reference counting no matter if you're done allocating or not.
- psyc 9y ago
  Ironically, no amount of care towards memory management could approach even one tenth of the care and attention I'm required to devote to memory management in Unity (and, FWIW, also in actual Windows .NET) to avoid frequent dropped frames. This is exactly what I was hoping to hear, thanks!
  - agmcleod 9y ago
    While I hear generally about garbage collection causing dropped frames. I've had this happen to me in HTML5 land. I haven't heard about it as much with Unity, that C# was fast enough, and the under the hood pieces are C++ anyways. Perhaps I'm reading the wrong channels :). I'm curious if your game project is 3D, and what sort of intensity you tend to have with it.
    - psyc 9y ago
      It depends entirely on the details that affect the GC. The biggest factors are the size and structure of your heap data. If the game uses a lot of memory, the GC will try to collect more often. If the heap data is large and graph-like (lots of refs to refs), it takes longer to walk.
  - robrtsql 9y ago
    Yep, I abandoned Unity after encountering the same issues as you. My experience is that every Unity GC run takes 10+ ms on my machine, even when there is no memory to clean up. I tried MonoGame once and the results were much better--garbage collection was fast when there wasn't much to do. However, I'd still choose a non-garbage-collected engine any day because I dislike lag spikes.
a_t48 9y ago
Unreal doesn't have GC as far as I know. Everything is built on C++ objects. There's some reference counting here and there, but I've not yet run into problems with it.
- psyc 9y ago
  https://docs.unrealengine.com/en-us/Programming/UnrealArchitecture/Objects/Optimizations#garbagecollection https://docs.unrealengine.com/en-us/Programming/UnrealArchit... I know very little about it, but in general there's a lot more information in the docs about the Garbage Collector than there is about how to not use it.
  - Danieru 9y ago
    Unreal does use GC and it is the stop the world variety, yet unlike unity the GC has never even showed up for us as a problem. I cannot tell you why or how but Unreal just handles GC better than Unity. I am speaking from my experience of shipping a commercial game on console with Unreal. Maybe things are worse on mobile.
    - a_t48 9y ago
      The difference is going to be what type of objects generate garbage. In Unity, everything you instantiate has the potential to make garbage (because C#), but for UE, it’s mostly top level objects which don’t have a lot of churn.
    - psyc 9y ago
      Great to know, thank you.
  - a_t48 9y ago
    TIL (thanks for the correction!) I guess they do this to break reference loops. The difference I guess is that it only applies to UObject derived things, which are higher level objects, rather than across your entire codebase. I’ve never seen GC take up processor time, but our project doesn’t have a lot of runtime churn of objects.
jeremiep 9y ago
I have yet to have any GC issues in a Unity project over 5 years of using it, even larger scale ones. But I would agree I rarely write "idiomatic" C#, I don't like many things about that style of programming in the first place to be honest. A garbage collector is rarely the issue; poor development practices and not planning memory usage patterns in the architecture will cost you orders of magnitude of performance long before the GC itself is an issue. Its not even hard to have zero GC allocations on ~99% of frames. This will give you better performance than the best GC implementations over bad allocation patterns ever could. This is also true of Unreal (UObjects are GC'd as you mentioned) and literally everything else using a GC; its not a free pass to forget about memory management. Thats one of the primary reasons why I rarely use code assets from the Asset Store; most people don't know how to write performant C# whatsoever; they get killed by a thousand cuts but none of them show up in the profiler, effectively wasting 90% of the CPU without any warning signs. (This is true of almost every software ever released.) I'm not one for premature micro-optimizations, but on the other hand I don't see how you can get any kind of performance without accounting for macro-optimizations from the very beginning. Blaming the GC for poor performance is pretty much the same as doing unbuffered byte-by-byte I/O and then wondering why its 1000x slower than the competition even after weeks of micro-optimizations.
- psyc 9y ago
  > Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#. I blame Unity's GC for what it is bad at. It's both stop-the-world and non-generational. As I said down-thread, it's a lot of work to design for avoiding allocations. Even then, Unity will still GC from time to time, and whether it matters will depend on the characteristics of your game's managed heap as a whole. This is the major stumbling block most times people argue with me about how GC is fine. Your data is like your data, because your app is your app. It's not like my data. The next step is not to use the managed heap for anything that isn't a temporary. Again, quite a bit of work. And the beginners and intermediates who are most of Unity's users aren't going to do it. Hell, in general I consider GC a non-starter for games, but sometimes I want to work at a company that uses C#. So I repeat: > Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.

by psyc 9y ago

robrtsql 9y ago

Sure! Hopefully a more experienced Godot dev will jump in and correct me if I'm wrong here.. Godot uses reference counting, but additionally supports a function which you can call on an object which will cause it to become 'unmanaged' by the reference counter, allowing you to free its memory on your own terms (or leak the memory, if you're not careful). Godot 3.0 added support for Mono, but I'm not sure how that works. I'm guessing that game objects in Godot are still reference counted, but now you also have memory allocated by the Mono runtime which will be garbage collected.

AlexAndThunder 9y ago
From: http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html http://docs.godotengine.org/en/3.0/getting_started/scripting... ' Memory management If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref function is provided for creating weak references. '
- jeremiep 9y ago
  Reference counting is a form of garbage collection. And depending on your usage patterns it might not even be the fastest one. Lots of increments/decrements on the refcount interleaved in normal code can kill the gains over a traditional GC that has nearly free allocation, batched finalizations and doesn't pollute the instruction stream with increments/decrements. Also with a traditional GC you pay nothing if you don't allocate memory; the collector will never run. You still pay the full price of reference counting no matter if you're done allocating or not.
psyc 9y ago
Ironically, no amount of care towards memory management could approach even one tenth of the care and attention I'm required to devote to memory management in Unity (and, FWIW, also in actual Windows .NET) to avoid frequent dropped frames. This is exactly what I was hoping to hear, thanks!
- agmcleod 9y ago
  While I hear generally about garbage collection causing dropped frames. I've had this happen to me in HTML5 land. I haven't heard about it as much with Unity, that C# was fast enough, and the under the hood pieces are C++ anyways. Perhaps I'm reading the wrong channels :). I'm curious if your game project is 3D, and what sort of intensity you tend to have with it.
  - psyc 9y ago
    It depends entirely on the details that affect the GC. The biggest factors are the size and structure of your heap data. If the game uses a lot of memory, the GC will try to collect more often. If the heap data is large and graph-like (lots of refs to refs), it takes longer to walk.
- robrtsql 9y ago
  Yep, I abandoned Unity after encountering the same issues as you. My experience is that every Unity GC run takes 10+ ms on my machine, even when there is no memory to clean up. I tried MonoGame once and the results were much better--garbage collection was fast when there wasn't much to do. However, I'd still choose a non-garbage-collected engine any day because I dislike lag spikes.

a_t48 9y ago

Unreal doesn't have GC as far as I know. Everything is built on C++ objects. There's some reference counting here and there, but I've not yet run into problems with it.

psyc 9y ago
https://docs.unrealengine.com/en-us/Programming/UnrealArchitecture/Objects/Optimizations#garbagecollection https://docs.unrealengine.com/en-us/Programming/UnrealArchit... I know very little about it, but in general there's a lot more information in the docs about the Garbage Collector than there is about how to not use it.
- Danieru 9y ago
  Unreal does use GC and it is the stop the world variety, yet unlike unity the GC has never even showed up for us as a problem. I cannot tell you why or how but Unreal just handles GC better than Unity. I am speaking from my experience of shipping a commercial game on console with Unreal. Maybe things are worse on mobile.
  - a_t48 9y ago
    The difference is going to be what type of objects generate garbage. In Unity, everything you instantiate has the potential to make garbage (because C#), but for UE, it’s mostly top level objects which don’t have a lot of churn.
  - psyc 9y ago
    Great to know, thank you.
- a_t48 9y ago
  TIL (thanks for the correction!) I guess they do this to break reference loops. The difference I guess is that it only applies to UObject derived things, which are higher level objects, rather than across your entire codebase. I’ve never seen GC take up processor time, but our project doesn’t have a lot of runtime churn of objects.

jeremiep 9y ago

I have yet to have any GC issues in a Unity project over 5 years of using it, even larger scale ones. But I would agree I rarely write "idiomatic" C#, I don't like many things about that style of programming in the first place to be honest. A garbage collector is rarely the issue; poor development practices and not planning memory usage patterns in the architecture will cost you orders of magnitude of performance long before the GC itself is an issue. Its not even hard to have zero GC allocations on ~99% of frames. This will give you better performance than the best GC implementations over bad allocation patterns ever could. This is also true of Unreal (UObjects are GC'd as you mentioned) and literally everything else using a GC; its not a free pass to forget about memory management. Thats one of the primary reasons why I rarely use code assets from the Asset Store; most people don't know how to write performant C# whatsoever; they get killed by a thousand cuts but none of them show up in the profiler, effectively wasting 90% of the CPU without any warning signs. (This is true of almost every software ever released.) I'm not one for premature micro-optimizations, but on the other hand I don't see how you can get any kind of performance without accounting for macro-optimizations from the very beginning. Blaming the GC for poor performance is pretty much the same as doing unbuffered byte-by-byte I/O and then wondering why its 1000x slower than the competition even after weeks of micro-optimizations.

psyc 9y ago
> Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#. I blame Unity's GC for what it is bad at. It's both stop-the-world and non-generational. As I said down-thread, it's a lot of work to design for avoiding allocations. Even then, Unity will still GC from time to time, and whether it matters will depend on the characteristics of your game's managed heap as a whole. This is the major stumbling block most times people argue with me about how GC is fine. Your data is like your data, because your app is your app. It's not like my data. The next step is not to use the managed heap for anything that isn't a temporary. Again, quite a bit of work. And the beginners and intermediates who are most of Unity's users aren't going to do it. Hell, in general I consider GC a non-starter for games, but sometimes I want to work at a company that uses C#. So I repeat: > Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.