4 ms·

A good thing. The C# bindings for Unity are great for scripting - the language is surprisingly suited to lightweight logic. This should be a nice gift to develo

A good thing. The C# bindings for Unity are great for scripting - the language is surprisingly suited to lightweight logic. This should be a nice gift to developers not yet familiar with C++.

garaetjjte 9y ago
For 'lightweight logic' maybe, but using GCed language for almost all logic executing every frame is bad idea.
- BoorishBears 9y ago
  C# has value types, it takes some careful coding to avoid GC stutters, but imo not nearly as careful as C++
  - thehardsphere 9y ago
    Uh, what? C++ doesn’t have garbage collection. Did I misread this comment?
    - com2kid 9y ago
      Still possible to have huge deallocations in C++. On top of that, C++ makes it possible to fragment memory, whereas .NET's GC can compact references. In both languages you have to be conscientious of types of allocations.
      - MaulingMonkey 9y ago
        I've had to deal with "huge" deallocations causing stuttering before - by e.g. deferring deallocation over several frames. Deferred deallocation is also occasionally important for working around use-after-free bugs in middleware or system APIs that you don't have the source code to. Building and using the tools to track down and break up circular references, dangling pointers, leaks, visualize memory fragmentation, etc. has eaten up a lot of my time. I've considered attempting to write what would amount to a compacting GC in a C++ codebase to deal with memory fragmentation issues before - but retrofitting such a beast into an existing codebase was a huge enough undertaking, that we went for other simpler half measures instead. Being unable to control some middleware and system allocations meant any such GC would involve half measures and hacks as well anyways.
    - tome 9y ago
      I read that as "[C#] takes some careful coding (to avoid GC stutters) but not nearly as careful as C++ [requires in general]".
      - thehardsphere 9y ago
        That would make more sense. I can see that now. Whether that tradeoff is the one to make probably depends a lot on what kind of game you are making.
    - org3432 9y ago
      The engine makes uses of shared pointers to do ref counting, and will deallocate unrefed objs for you. Additionally there is a built in asset GC system.
    - WillPostForFood 9y ago
      Unreal C++ has garbage collection: https://wiki.unrealengine.com/Garbage_Collection_Overview https://wiki.unrealengine.com/Garbage_Collection_Overview
    - pjmlp 9y ago
      Actually C++11 has a GC API and Unreal does make use of a C++ GC.
- apk-d 9y ago
  Just because it's GC'd doesn't mean it's constantly allocating memory. Optimizing the most common heap allocation sources isn't very difficult (especially compared to the nightmare of manual memory management). I recommend running the Roslyn Clr Heap Allocation Analyzer extension for VS for a few days - it helps to learn which language features and APIs implicitly allocate objects (or box value type objects). Plus, modern GC implementations are super clever and efficient (as opposed to the implementation used by Unity, which unfortunately rather sucks, but I hear they're working on swapping it out).
  - psyc 9y ago
    I wrote games and engines in C++ for 15 years, and Unity for about 5. I strongly prefer manual mem management, hands down. Optimizing for Unity's GC, in pathological situations, is the nightmare. If the game is relatively simple, and the heap relatively small, it's not a big problem. But if you're trying to make a large, complex simulation that's actually pushing boundaries, the GC becomes a constant adversary. People always talk about allocations, but not allocating during a frame is just the minimum price of admission. The real trouble is the static characteristics of the heap, like size and graph complexity. With manual alloc, at least the problem is straightforward: don't leak, and don't dangle. With a black-box GC, where you can't even hint to it about the lifetimes of objects, you have to be much, much more aware of memory management, then go through a lot of different non-idiomatic contortions regarding every single thing you put on the heap.
    - pjmlp 9y ago
      Unity GC is a bad example, because it is widely known that their implementation is pretty crappy, frozen in 2007 implementation. The majority of GC implementations out there are generations ahead of what Unity's GC is capable of.

A good thing. The C# bindings for Unity are great for scripting - the language is surprisingly suited to lightweight logic. This should be a nice gift to developers not yet familiar with C++.

garaetjjte 9y ago

For 'lightweight logic' maybe, but using GCed language for almost all logic executing every frame is bad idea.

BoorishBears 9y ago
C# has value types, it takes some careful coding to avoid GC stutters, but imo not nearly as careful as C++
- thehardsphere 9y ago
  Uh, what? C++ doesn’t have garbage collection. Did I misread this comment?
  - com2kid 9y ago
    Still possible to have huge deallocations in C++. On top of that, C++ makes it possible to fragment memory, whereas .NET's GC can compact references. In both languages you have to be conscientious of types of allocations.
    - MaulingMonkey 9y ago
      I've had to deal with "huge" deallocations causing stuttering before - by e.g. deferring deallocation over several frames. Deferred deallocation is also occasionally important for working around use-after-free bugs in middleware or system APIs that you don't have the source code to. Building and using the tools to track down and break up circular references, dangling pointers, leaks, visualize memory fragmentation, etc. has eaten up a lot of my time. I've considered attempting to write what would amount to a compacting GC in a C++ codebase to deal with memory fragmentation issues before - but retrofitting such a beast into an existing codebase was a huge enough undertaking, that we went for other simpler half measures instead. Being unable to control some middleware and system allocations meant any such GC would involve half measures and hacks as well anyways.
  - tome 9y ago
    I read that as "[C#] takes some careful coding (to avoid GC stutters) but not nearly as careful as C++ [requires in general]".
    - thehardsphere 9y ago
      That would make more sense. I can see that now. Whether that tradeoff is the one to make probably depends a lot on what kind of game you are making.
  - org3432 9y ago
    The engine makes uses of shared pointers to do ref counting, and will deallocate unrefed objs for you. Additionally there is a built in asset GC system.
  - WillPostForFood 9y ago
    Unreal C++ has garbage collection: https://wiki.unrealengine.com/Garbage_Collection_Overview https://wiki.unrealengine.com/Garbage_Collection_Overview
  - pjmlp 9y ago
    Actually C++11 has a GC API and Unreal does make use of a C++ GC.
apk-d 9y ago
Just because it's GC'd doesn't mean it's constantly allocating memory. Optimizing the most common heap allocation sources isn't very difficult (especially compared to the nightmare of manual memory management). I recommend running the Roslyn Clr Heap Allocation Analyzer extension for VS for a few days - it helps to learn which language features and APIs implicitly allocate objects (or box value type objects). Plus, modern GC implementations are super clever and efficient (as opposed to the implementation used by Unity, which unfortunately rather sucks, but I hear they're working on swapping it out).
- psyc 9y ago
  I wrote games and engines in C++ for 15 years, and Unity for about 5. I strongly prefer manual mem management, hands down. Optimizing for Unity's GC, in pathological situations, is the nightmare. If the game is relatively simple, and the heap relatively small, it's not a big problem. But if you're trying to make a large, complex simulation that's actually pushing boundaries, the GC becomes a constant adversary. People always talk about allocations, but not allocating during a frame is just the minimum price of admission. The real trouble is the static characteristics of the heap, like size and graph complexity. With manual alloc, at least the problem is straightforward: don't leak, and don't dangle. With a black-box GC, where you can't even hint to it about the lifetimes of objects, you have to be much, much more aware of memory management, then go through a lot of different non-idiomatic contortions regarding every single thing you put on the heap.
  - pjmlp 9y ago
    Unity GC is a bad example, because it is widely known that their implementation is pretty crappy, frozen in 2007 implementation. The majority of GC implementations out there are generations ahead of what Unity's GC is capable of.