7 ms·

I have memories of people trying Java for the same purpose. I believe, the C# will ultimately meet the same fate. Here is why (I believe that): Switching from

I have memories of people trying Java for the same purpose. I believe, the C# will ultimately meet the same fate. Here is why (I believe that): Switching from C/C++ to a GC language is nothing like switching from Assembler to C/C++. We did not write Assembler because we liked it. We wrote it because we targeted 8/16-bit archs, which did not fit C/C++ memory model quite well. Because of this Assembler had huge speed and size advantage. As soon as flat memory archs became viable almost everybody dropped Assembler without regret. We lost a bit of performance (which could have been easily regained by rewriting inner loops in Assembler) in exchange of reusable, portable code, type system and terse program texts. These allowed to write much more complex games by engaging bigger teams who could sensibly collaborate over a much bigger project in C/C++. What is the transition to GC from C++? You sacrifice a lot of performance for freedom from managing memory. I don't know about other people but having shipped few AAA games my only concern was fitting shit into available memory (which GC does not help, to say the least). You allocate memory on load. If you load multiple levels you nuke the previous level's memory. If you stream you do the same but your "levels" are now "segments" in a pool. Of course, if you want to go full-GC and allocate your structures byte by byte, uint32_t by uint32_t - be my guest, not sure how you plan to compete but, hey, load times (same as frame rate) are not that important as they say on the internet :) Nevertheless, as soon as 32-bit targets become completely obsolete people will find out that you can pre-allocate everything off-line in 64-bit so all you will have to do at run-time is map/unmap pages (which GC won't help either). In conclusion: one dropped performance on the floor (due to cache issues, SIMD issues, off-line vs JIT quality issues etc) and picked up the solution to the problem one should not have had in the first place.

caseymarquis 10y ago
Maybe Nim would be a good GC included C++ replacement then? Its GC can reliably be constrained to a maximum run time of 2ms, and it has strong macro support.
- pandaman 10y ago
  IMO, 2ms is too much for strong macro support. Even if GC had 0 run-time cost I'd still rather use C++ since 99.9% of my code is creating memory structures of particular layout (I write graphics). To write the same code in a GC language I'd have to map memory to a file and then use the strong macro system to emulate native struct type from C++ :)
  - nonsince 10y ago
    This is Nim vs C#, not Nim vs C++. If you're writing hot loops and graphics code a GC is utterly anathema to your goals. I think given 5/10 years Rust will be the language of choice here, but the ecosystem is nowhere near good enough yet.
    - pandaman 10y ago
      As of now I don't see any problems with C++. I doubt Rust is going to offer something so much better that people will abandon the tools they already have for these benefits. Though, who knows? I never touched Rust.
      - pjmlp 10y ago
        It just needs a OS company to pick it up and push it down dev throats, like it happened before with C and C++. If you want the goodies on Windows you need C++, if you want the goodies on iOS and OS X you needed Objective-C and now Swift as well, the goodies on Android require Java, the goodies on consoles moved from C to C++. Same here, if tomorrow one of those companies decides their SDK should be Language X, anyone that wants a piece of the pie will learn Language X.
        TuringTest 10y ago
        This could come from a IoT company that does things well. A company providing unsupervised devices would benefit from a OS with a strong approach to avoiding security bugs.
nonsince 10y ago
C# is, among GC languages, particularly bloated with regards to memory. There is huge amounts of runtime type information (including stringified versions of everything) and you have close to no control over memory management without hooking into ugly APIs. I wish that Swift or Rust had been usable early enough to get swept up in the hype train so that we could avoid this crap. Also, it would mean I didn't have to use OOP to write games.
- golergka 10y ago
  C# specifies the language, not the runtime. Apart from .NET and Mono, you can compile C# to cpp (what Unity does under the hood, btw). > Also, it would mean I didn't have to use OOP to write games. There are many instances where other programming paradigms are more usable - but in my experience, gameplay logic, specifically, maps very well onto classic OOP concepts.
  - nonsince 10y ago
    If gameplay mapped well onto OOP then the big game companies would use it, and not data-driven programming (specifically, entity-component systems). I think that there are a couple things that require OOP-style dynamic dispatch, but they don't need to be pervasive, even a function pointer stored as a struct member is more than enough to provide all the benefits of OOP without having to take on all the drawbacks.
- jameshart 10y ago
  You should take a look at what is going on in the latest dotnet core CLR and C# compiler around 'ref-like' types and Span<>s. Basically a way to let you write 'safe' C# code that interacts with memory that is allocated in different ways (for example with controlled allocation outside of the GC). Since C# is a multiparadigm language with strong functional as well as OO fundamentals, I suspect it will make it possible for libraries and frameworks to be built which enable allocation free code in C# gameloops. It's not just game engines which have these requirements - the same functionality is also critical for high performance servers, and machine learning applications, so this is a language feature with a lot of demand.
pjmlp 10y ago
Java only failed because Sun didn't care enough for pushing it into game developers after their initial presentations. Actually they didn't care for any other scenario that wasn't JEE, in terms of putting resources into it. Switching from Assembly into C, Pascal, Modula-2, QuickBasic was mostly an amateur thing until SDKs started to be based on C. Same with C++, we were the outliers until console vendors started pushing C++ into devs. See Mike Acton's talks about about how he enjoyed having been forced to move from C into C++. The thing with GC is not the freedom to manage memory, you still need to take care about how memory is managed. What one gets is type safety and an uniform way to manage memory across libraries. You know exactly who is responsible for releasing it, there are no double deallocations, releasing invalid addresses, or having to deal with library specific smart pointers (CPtr, QSmartPtr, unique_ptr, my_in-house_ptr, ...). > due to cache issues, SIMD issues, off-line vs JIT quality issues etc Having a GC doesn't preclude lack of support for cache handling or SIMD. Many GC based languages have such support and actually C# 7 with Microsoft's toolchain (not Unity's one) does offer such features, even if they can still be improved. As for JIT quality, it is no different from any other compiler, otherwise as I referred, why not discuss C performance using MS-DOS compiler's benchmarks.
- pandaman 10y ago
  >Same with C++, we were the outliers until console vendors started pushing C++ into devs. See Mike Acton's talks about about how he enjoyed having been forced to move from C into C++. The first (major) console C++ SDK library is GNM/GNMX for PS4. Are you saying C++ games has been outliers till 201x? I guess this depends on how you define outliers then. Other than the guy casting his game writing on youtube (Code Hero?) I don't know of any significant titles in C past 2000. I have not seen all the games but I shipped a few myself and have friends working on many more and nobody that I know had been writing pure C. Think of all vtbl-> you'd have to write if you are targeting Windows/Xbox just for the pleasure to name your source file .c instead of .cpp! >What one gets is type safety Thanks, we've got this in C++ already. >You know exactly who is responsible for releasing it, there are no double deallocations, releasing invalid addresses, or having to deal with library specific smart pointers (CPtr, QSmartPtr, unique_ptr, my_in-house_ptr, ...). Never had been a problem for me. The only game I touched that had smart pointers had them because it used NetImmerse and it got cancelled anyways. >Having a GC doesn't preclude lack of support for cache handling or SIMD. I don't know what is cache handling, to be honest, but what I meant is that, since GC moves stuff around memory, it's likely to create cache hazards. And since it probably uses a single pool, you cannot change cache policies on per-entity basis. >As for JIT quality, it is no different from any other compiler, otherwise as I referred, why not discuss C performance using MS-DOS compiler's benchmarks. Really? You believe JIT will be on-par with a profile assisted, bruteforcing compiler, which can spend a week optimizing a single function?
golergka 10y ago
You're forgetting that this transition takes place in game engines: so the critical path is still mostly C++, while C# is responsible for game logic and most of it is run on callbacks, not in the update loop. Same goes for memory: textures and other assets are managed through the engine; C# only contains game logic data and handles to the assets.
animal531 10y ago
I was once working on a solo indie game using C# with OpenGL bindings. If you create it along the normal program lines of object instantiate/use/destroy (and repeat), then you're soon going to run into serious issues. At the time I had many issues with the GC, Large Object Heap and fragmentation (although this had still been in a much older .NET version). For a game project, both for speed and memory, you want as much as possible to be pre-allocated (and all at once). During run-time you want as few objects as possible being instantiated, that way you save cycles on both the objects, and eventually on the GC. Of course it's not always that easy. After that it depends on your targets, you'll never fit a Unity C# game as tightly into any target as a native app, but it's a trade-off that's worth making in many cases.
maccard 10y ago
In UE4 everything is garbage collected. Lots of high performance, AAA games using it.

caseymarquis 10y ago

Maybe Nim would be a good GC included C++ replacement then? Its GC can reliably be constrained to a maximum run time of 2ms, and it has strong macro support.

pandaman 10y ago
IMO, 2ms is too much for strong macro support. Even if GC had 0 run-time cost I'd still rather use C++ since 99.9% of my code is creating memory structures of particular layout (I write graphics). To write the same code in a GC language I'd have to map memory to a file and then use the strong macro system to emulate native struct type from C++ :)
- nonsince 10y ago
  This is Nim vs C#, not Nim vs C++. If you're writing hot loops and graphics code a GC is utterly anathema to your goals. I think given 5/10 years Rust will be the language of choice here, but the ecosystem is nowhere near good enough yet.
  - pandaman 10y ago
    As of now I don't see any problems with C++. I doubt Rust is going to offer something so much better that people will abandon the tools they already have for these benefits. Though, who knows? I never touched Rust.
    - pjmlp 10y ago
      It just needs a OS company to pick it up and push it down dev throats, like it happened before with C and C++. If you want the goodies on Windows you need C++, if you want the goodies on iOS and OS X you needed Objective-C and now Swift as well, the goodies on Android require Java, the goodies on consoles moved from C to C++. Same here, if tomorrow one of those companies decides their SDK should be Language X, anyone that wants a piece of the pie will learn Language X.
      - TuringTest 10y ago
        This could come from a IoT company that does things well. A company providing unsupervised devices would benefit from a OS with a strong approach to avoiding security bugs.

nonsince 10y ago

C# is, among GC languages, particularly bloated with regards to memory. There is huge amounts of runtime type information (including stringified versions of everything) and you have close to no control over memory management without hooking into ugly APIs. I wish that Swift or Rust had been usable early enough to get swept up in the hype train so that we could avoid this crap. Also, it would mean I didn't have to use OOP to write games.

golergka 10y ago
C# specifies the language, not the runtime. Apart from .NET and Mono, you can compile C# to cpp (what Unity does under the hood, btw). > Also, it would mean I didn't have to use OOP to write games. There are many instances where other programming paradigms are more usable - but in my experience, gameplay logic, specifically, maps very well onto classic OOP concepts.
- nonsince 10y ago
  If gameplay mapped well onto OOP then the big game companies would use it, and not data-driven programming (specifically, entity-component systems). I think that there are a couple things that require OOP-style dynamic dispatch, but they don't need to be pervasive, even a function pointer stored as a struct member is more than enough to provide all the benefits of OOP without having to take on all the drawbacks.
jameshart 10y ago
You should take a look at what is going on in the latest dotnet core CLR and C# compiler around 'ref-like' types and Span<>s. Basically a way to let you write 'safe' C# code that interacts with memory that is allocated in different ways (for example with controlled allocation outside of the GC). Since C# is a multiparadigm language with strong functional as well as OO fundamentals, I suspect it will make it possible for libraries and frameworks to be built which enable allocation free code in C# gameloops. It's not just game engines which have these requirements - the same functionality is also critical for high performance servers, and machine learning applications, so this is a language feature with a lot of demand.

pjmlp 10y ago

Java only failed because Sun didn't care enough for pushing it into game developers after their initial presentations. Actually they didn't care for any other scenario that wasn't JEE, in terms of putting resources into it. Switching from Assembly into C, Pascal, Modula-2, QuickBasic was mostly an amateur thing until SDKs started to be based on C. Same with C++, we were the outliers until console vendors started pushing C++ into devs. See Mike Acton's talks about about how he enjoyed having been forced to move from C into C++. The thing with GC is not the freedom to manage memory, you still need to take care about how memory is managed. What one gets is type safety and an uniform way to manage memory across libraries. You know exactly who is responsible for releasing it, there are no double deallocations, releasing invalid addresses, or having to deal with library specific smart pointers (CPtr, QSmartPtr, unique_ptr, my_in-house_ptr, ...). > due to cache issues, SIMD issues, off-line vs JIT quality issues etc Having a GC doesn't preclude lack of support for cache handling or SIMD. Many GC based languages have such support and actually C# 7 with Microsoft's toolchain (not Unity's one) does offer such features, even if they can still be improved. As for JIT quality, it is no different from any other compiler, otherwise as I referred, why not discuss C performance using MS-DOS compiler's benchmarks.

pandaman 10y ago
>Same with C++, we were the outliers until console vendors started pushing C++ into devs. See Mike Acton's talks about about how he enjoyed having been forced to move from C into C++. The first (major) console C++ SDK library is GNM/GNMX for PS4. Are you saying C++ games has been outliers till 201x? I guess this depends on how you define outliers then. Other than the guy casting his game writing on youtube (Code Hero?) I don't know of any significant titles in C past 2000. I have not seen all the games but I shipped a few myself and have friends working on many more and nobody that I know had been writing pure C. Think of all vtbl-> you'd have to write if you are targeting Windows/Xbox just for the pleasure to name your source file .c instead of .cpp! >What one gets is type safety Thanks, we've got this in C++ already. >You know exactly who is responsible for releasing it, there are no double deallocations, releasing invalid addresses, or having to deal with library specific smart pointers (CPtr, QSmartPtr, unique_ptr, my_in-house_ptr, ...). Never had been a problem for me. The only game I touched that had smart pointers had them because it used NetImmerse and it got cancelled anyways. >Having a GC doesn't preclude lack of support for cache handling or SIMD. I don't know what is cache handling, to be honest, but what I meant is that, since GC moves stuff around memory, it's likely to create cache hazards. And since it probably uses a single pool, you cannot change cache policies on per-entity basis. >As for JIT quality, it is no different from any other compiler, otherwise as I referred, why not discuss C performance using MS-DOS compiler's benchmarks. Really? You believe JIT will be on-par with a profile assisted, bruteforcing compiler, which can spend a week optimizing a single function?

golergka 10y ago

You're forgetting that this transition takes place in game engines: so the critical path is still mostly C++, while C# is responsible for game logic and most of it is run on callbacks, not in the update loop. Same goes for memory: textures and other assets are managed through the engine; C# only contains game logic data and handles to the assets.

animal531 10y ago

I was once working on a solo indie game using C# with OpenGL bindings. If you create it along the normal program lines of object instantiate/use/destroy (and repeat), then you're soon going to run into serious issues. At the time I had many issues with the GC, Large Object Heap and fragmentation (although this had still been in a much older .NET version). For a game project, both for speed and memory, you want as much as possible to be pre-allocated (and all at once). During run-time you want as few objects as possible being instantiated, that way you save cycles on both the objects, and eventually on the GC. Of course it's not always that easy. After that it depends on your targets, you'll never fit a Unity C# game as tightly into any target as a native app, but it's a trade-off that's worth making in many cases.

maccard 10y ago

In UE4 everything is garbage collected. Lots of high performance, AAA games using it.