5 ms·

And yet there are GCs in Unity and Unreal Engine, the most popular game engines of today.

by p0nce 8y ago

swsieber 8y ago
Electron is a very popular application framework today.
monocasa 8y ago
Only the scripting code is GCed. The core engine in both cases is C++ with manual memory management for the reasons stated above.
- pjmlp 8y ago
  On Unity's case with some subsystems in the process of being replaced by HPC#. And in Unreal you can use GC in whatever components you feel like, it is a matter of weighting where it makes sense.
  - kllrnohj 8y ago
    > On Unity's case with some subsystems in the process of being replaced by HPC#. They are converting their C# code to HPC# which specifically does not do GC allocations. https://youtu.be/NF6kcNS6U80?t=886 https://youtu.be/NF6kcNS6U80?t=886 HPC#: * no class types * no boxing * no GC allocation * not exceptions for control flow They are building a compiler to eliminate the GC from the GC'd language they were using.
    - pjmlp 8y ago
      Once upon a time, C code for games engines looked like this. void do_stuff(void) { asm { } } Hardly any C code in sight, and most of the stuff could equally have been coded in MASM/TASM with their higher level macros. Eventually game devs migrated to proper C. A couple of years later, C++ code in game engines, was not even "C with Classes", rather C compiled with C++ compiler. Eventually game devs migrated to proper C++. Looking at the past, which I was partially part of, I see HPC# as a stepping stone into regular C#, in a similar vein that C code of yore was full of inline Assembly. It is of course a matter of opinion, however I like to look at the past to see where the future leads to. So lets see who's is right in about 10 years, regarding how game engines get implemented.
      - kllrnohj 8y ago
        Except they are stepping AWAY from C# here, not towards it. And the game-industry as a whole is moving to data-oriented design, which tends to be hard to do at best (if not downright impossible) in most GC'd languages. Regardless the transition from C to C++ has no performance cost (often a performance advatnage), so I'm not sure why you're bringing that up as some significant migration in this case? It doesn't support any argument for a transition from C++ to C# or similar, as that comes with a huge performance cost. Particularly in an era where CPU performance hasn't improved for almost a decade now.
        pjmlp 8y ago
        Modern CPU performance gets explored by taking advantage of multi-core, and GC is a very helpful tool for writing lock-free data structures. Additionally dataflow languages are better suited for GPGPU programming than plain old C and C++, as Google is exploring with XLA on Tensorflow, and game engines with graphical tooling for shader generation. Again, lets come back in 10 years and see who was actually right.

And yet there are GCs in Unity and Unreal Engine, the most popular game engines of today.

by p0nce 8y ago

And yet there are GCs in Unity and Unreal Engine, the most popular game engines of today.

swsieber 8y ago

Electron is a very popular application framework today.

monocasa 8y ago

Only the scripting code is GCed. The core engine in both cases is C++ with manual memory management for the reasons stated above.

pjmlp 8y ago
On Unity's case with some subsystems in the process of being replaced by HPC#. And in Unreal you can use GC in whatever components you feel like, it is a matter of weighting where it makes sense.
- kllrnohj 8y ago
  > On Unity's case with some subsystems in the process of being replaced by HPC#. They are converting their C# code to HPC# which specifically does not do GC allocations. https://youtu.be/NF6kcNS6U80?t=886 https://youtu.be/NF6kcNS6U80?t=886 HPC#: * no class types * no boxing * no GC allocation * not exceptions for control flow They are building a compiler to eliminate the GC from the GC'd language they were using.
  - pjmlp 8y ago
    Once upon a time, C code for games engines looked like this. void do_stuff(void) { asm { } } Hardly any C code in sight, and most of the stuff could equally have been coded in MASM/TASM with their higher level macros. Eventually game devs migrated to proper C. A couple of years later, C++ code in game engines, was not even "C with Classes", rather C compiled with C++ compiler. Eventually game devs migrated to proper C++. Looking at the past, which I was partially part of, I see HPC# as a stepping stone into regular C#, in a similar vein that C code of yore was full of inline Assembly. It is of course a matter of opinion, however I like to look at the past to see where the future leads to. So lets see who's is right in about 10 years, regarding how game engines get implemented.
    - kllrnohj 8y ago
      Except they are stepping AWAY from C# here, not towards it. And the game-industry as a whole is moving to data-oriented design, which tends to be hard to do at best (if not downright impossible) in most GC'd languages. Regardless the transition from C to C++ has no performance cost (often a performance advatnage), so I'm not sure why you're bringing that up as some significant migration in this case? It doesn't support any argument for a transition from C++ to C# or similar, as that comes with a huge performance cost. Particularly in an era where CPU performance hasn't improved for almost a decade now.
      - pjmlp 8y ago
        Modern CPU performance gets explored by taking advantage of multi-core, and GC is a very helpful tool for writing lock-free data structures. Additionally dataflow languages are better suited for GPGPU programming than plain old C and C++, as Google is exploring with XLA on Tensorflow, and game engines with graphical tooling for shader generation. Again, lets come back in 10 years and see who was actually right.