7 ms·

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

deleted 11y ago
[deleted]
panamafrank 11y ago
yes and no, while the previous GC pauses wouldn't have really affected anything the size of a hobby game, the improvements are welcome. The bigger problem with Go regarding game development is operator overloading and interfacing with C, the latter being a pain when it comes to memory management.
- martijn_himself 11y ago
  Would these GC improvements put Golang in the same league as C# (which is widely used for game development e.g. Unity3D, the .NET runtime has a GC) or can these comparisons not be made?
  - pjmlp 11y ago
    As heads up when talking about Unity3D, please be aware of the pre-historic .NET runtime they still are shipping versus what Xamarin and Microsoft deliver. So always take the JIT/GC complains in Unity3D context with that caveat in mind.
    - martijn_himself 11y ago
      Thanks. Whilst I was aware that Unity3D was shipping with an ancient version of Mono (and more or less consequently with an ancient version of C#), I wasn't aware there were a lot of JIT/GC related complaints against it.
      - pjmlp 11y ago
        I have dual feelings with regard to Unity guys. On one side they did a great job increasing the visibility of C# among game developers, which tend to only switch languages when the OS and console SDKs push them to do so. On the other hand, they spread the feeling that C# is bad for game development among developers that don't understand "language != implementation" and take their Unity's experience as how C# implementations performs in general. However I also should say that they are aware of it and planing to improve the situation after their IL2CPP compiler stabilizes.
pjmlp 11y ago
It all depends on which games people intend to write. Apparently younger generations are unaware that C was seen as a managed language in the 80's and early 90's, with compilers not generating good enough code for game development. In the 90's I have seen lots of Turbo Pascal and C code where the functions where plain wrappers for inline Assembly. So unless you intend to write Crysis in Go, there are lots of games you can write with it.
benchin 11y ago
absolutely - if you want to write your games for the terminal https://github.com/JoelOtter/termloop https://github.com/JoelOtter/termloop
malkia 11y ago
To be honest, for 60fps, and now with VR - 120fps and more - it won't be good enough. But... I could be wrong... Lots of games do have additional scripting languages (.gsc in COD games, lua in others, etc., etc.) - these all have garbage collectors. The key to control that is checking your high watermarks (while playing the level), and doing incremental GC. Whether you can write the whole game in it - I don't know, but it'll be pretty good for tools/editors/pipeline/etc.
heavenlyhash 11y ago
I would say "yes", based on this project: https://github.com/thinkofdeath/steven https://github.com/thinkofdeath/steven It's a voxel game based on OpenGL. It implements much of vanilla minecraft. Annecdotally, I'd say it performs much better for me than minecraft itself does, at longer view distances, and with essentially no observable GC pauses (of which minecraft suffers quite visibly). Also, a stabler heap size, etc. The capabilities are definitely there. I'm spending some of my weekend moments playing around with more GL stuff based on what I've learned from reading this project, and it's quite fun. Build times are right up there where you'd expect, too -- seconds or less! (The first build takes a few moments for running gcc for the c bindings to GL, but after that, those cache nicely.) A 1-second turnaround for recompiling a whole game is an incredible breath of fresh air. And of course, I shipped my demo game to a friend on a mac the same day I started writing. I'm on a linux. Not bad.
- martijn_himself 11y ago
  I can't access that link at the moment but I will have a look at it, thank you. I had exactly the same idea- to play around with bindings to OpenGL and build some demos.
espadrine 11y ago
You have to ensure that the GC never makes you drop a frame. For 60Hz, that means staying below 16.7ms. Given that a Go 1.6 GC will still take about 4ms, you have 12.7ms to generate a frame, which can be too limiting for some CPU-intensive games, but is perfectly acceptable for many games. (In Go 1.5, a GC was much more likely to make you drop a frame, as it could easily average 40ms.) On the other hand, there are less high-quality libraries in Go than in C++ or in JS. That may be the most limiting factor.
- martijn_himself 11y ago
  I just have to say this is a great answer. Thanks.
- mike_hearn 11y ago
  Interesting fact: Unreal Engine uses a GCd heap (or used to at least) for its core game state, so that means many AAA games use GC. And you can hit 60fps with it. Their secret is they keep the game state heap really small. Like, 50 megabytes, maybe.
  - pjmlp 11y ago
    They still do https://docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/Objects/Optimizations/index.html#garbagecollection https://docs.unrealengine.com/latest/INT/Programming/UnrealA...
- twotwotwo 11y ago
  Another weird thing is, the background collection is still using a core (plus somewhat slowing foreground code, with write barriers) when it runs. It's kinda like you have a varying amount of CPU power. One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twiddle without looking too glitchy, maybe you can figure out some way to shed work when you start to fall behind. It'd be really cool to see someone attempt a game or such in Go--boundary pushing's always fun, more so when the boundaries are recently expanded.
omginternets 11y ago
In addition to what others have said, you can relieve much of the pressure on the GC by making liberal use of `sync.Pool`.
Jach 11y ago
Lots of neat and profitable games have been made in slower languages, so you should be fine, though in some cases you might have to replicate an entire engine... Not being real familiar with Go, the thing you'll want to look out for if your game gets "big" is unpredictable GC events, more-so even than the absolute max duration of any particular GC event. If Go (or whatever else) doesn't provide enough tuning to support "soft" realtime systems, you'll end up structuring your program to allocate in pools and release all references only at certain points to try and make the GC predictable, which is a common pattern for non-GC languages in games, so you've all but lost the let-me-not-care-about-memory-management justification for the language except for the safety aspects, which don't tend to be high priority for games...
_ph_ 11y ago
It should be suitable - but whether it is depends also on your memory usage. GCs are not black boxes which magically work or not work. They do get bad reputation by people who do heap allocations without thinking about them. They key to good GC performance is about the allocation profile. GO gives you very good control about heap allocation, so it should be possible to arrange the main game loop such that no fresh heap is allocated, which also would mean that the GC does not run. The GO GC runs when, the allocated heap grow to a set multiple (by default 2x) of the heap size after the last GC run. Adjusting this factor to your memory usage should give you pretty good control when the GC runs and when not.
AsyncAwait 11y ago
Nim (http://nim-lang.org http://nim-lang.org), is a language in some ways filling a similar niche to Go and they are suitable for games, because you can tune or even change the GC. Not the case with Go, so may be less suitable for soft real-time like games.
blakeyrat 11y ago
There are a heck of a lot games written in C#, which is not only interpreted, but probably has a less-tuned GC. Including heavy-processors like Kerbal Space Program. If KSP works in C#, you can write a game in Go no problem.
- djur 11y ago
  C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.
  - masklinn 11y ago
    > C# is not interpreted Unless you're asserting that e.g. Python is not interpreted; or you're using the relatively recent native toolchain, C# is interpreted. That's its original state and its widest deployment pattern.
    - gecko 11y ago
      You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted. It is true that .NET programs are traditionally distributed as CLR bytecode. This is similar to a .class file or a .pyc file. But the CLR does now, and always has, had a JIT. E.g., the first line or two of https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).aspx https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).a... , which is for .NET 1.1, which explicitly states that, even at that time, the bytecode is JITed prior to execution.
      - masklinn 11y ago
        > You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted. No and no. > But the CLR does now, and always has, had a JIT. And Python has had a JIT[0] for as long as the framework has existed. [0] https://en.wikipedia.org/wiki/Psyco https://en.wikipedia.org/wiki/Psyco now replaced by the pypy project
tossableacct11 11y ago
So I wondered that as well and did some Googling. Found a blog post by Joel Webber, who I have not heard of, but he was working on a minecraft clone and had some advice on avoiding GC and memory layout: http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go Also found an engine, Azul 3D, and they made this claim: https://azul3d.org/doc/faq.html#what-about-the-garbage-collector https://azul3d.org/doc/faq.html#what-about-the-garbage-colle... Then there is termloop, which is a terminal based engine: https://github.com/JoelOtter/termloop https://github.com/JoelOtter/termloop Fun for indie game stuff. So, yeah. There's that.

deleted 11y ago

[deleted]

panamafrank 11y ago

yes and no, while the previous GC pauses wouldn't have really affected anything the size of a hobby game, the improvements are welcome. The bigger problem with Go regarding game development is operator overloading and interfacing with C, the latter being a pain when it comes to memory management.

martijn_himself 11y ago
Would these GC improvements put Golang in the same league as C# (which is widely used for game development e.g. Unity3D, the .NET runtime has a GC) or can these comparisons not be made?
- pjmlp 11y ago
  As heads up when talking about Unity3D, please be aware of the pre-historic .NET runtime they still are shipping versus what Xamarin and Microsoft deliver. So always take the JIT/GC complains in Unity3D context with that caveat in mind.
  - martijn_himself 11y ago
    Thanks. Whilst I was aware that Unity3D was shipping with an ancient version of Mono (and more or less consequently with an ancient version of C#), I wasn't aware there were a lot of JIT/GC related complaints against it.
    - pjmlp 11y ago
      I have dual feelings with regard to Unity guys. On one side they did a great job increasing the visibility of C# among game developers, which tend to only switch languages when the OS and console SDKs push them to do so. On the other hand, they spread the feeling that C# is bad for game development among developers that don't understand "language != implementation" and take their Unity's experience as how C# implementations performs in general. However I also should say that they are aware of it and planing to improve the situation after their IL2CPP compiler stabilizes.

pjmlp 11y ago

It all depends on which games people intend to write. Apparently younger generations are unaware that C was seen as a managed language in the 80's and early 90's, with compilers not generating good enough code for game development. In the 90's I have seen lots of Turbo Pascal and C code where the functions where plain wrappers for inline Assembly. So unless you intend to write Crysis in Go, there are lots of games you can write with it.

benchin 11y ago

absolutely - if you want to write your games for the terminal https://github.com/JoelOtter/termloop https://github.com/JoelOtter/termloop

malkia 11y ago

To be honest, for 60fps, and now with VR - 120fps and more - it won't be good enough. But... I could be wrong... Lots of games do have additional scripting languages (.gsc in COD games, lua in others, etc., etc.) - these all have garbage collectors. The key to control that is checking your high watermarks (while playing the level), and doing incremental GC. Whether you can write the whole game in it - I don't know, but it'll be pretty good for tools/editors/pipeline/etc.

heavenlyhash 11y ago

I would say "yes", based on this project: https://github.com/thinkofdeath/steven https://github.com/thinkofdeath/steven It's a voxel game based on OpenGL. It implements much of vanilla minecraft. Annecdotally, I'd say it performs much better for me than minecraft itself does, at longer view distances, and with essentially no observable GC pauses (of which minecraft suffers quite visibly). Also, a stabler heap size, etc. The capabilities are definitely there. I'm spending some of my weekend moments playing around with more GL stuff based on what I've learned from reading this project, and it's quite fun. Build times are right up there where you'd expect, too -- seconds or less! (The first build takes a few moments for running gcc for the c bindings to GL, but after that, those cache nicely.) A 1-second turnaround for recompiling a whole game is an incredible breath of fresh air. And of course, I shipped my demo game to a friend on a mac the same day I started writing. I'm on a linux. Not bad.

martijn_himself 11y ago
I can't access that link at the moment but I will have a look at it, thank you. I had exactly the same idea- to play around with bindings to OpenGL and build some demos.

espadrine 11y ago

You have to ensure that the GC never makes you drop a frame. For 60Hz, that means staying below 16.7ms. Given that a Go 1.6 GC will still take about 4ms, you have 12.7ms to generate a frame, which can be too limiting for some CPU-intensive games, but is perfectly acceptable for many games. (In Go 1.5, a GC was much more likely to make you drop a frame, as it could easily average 40ms.) On the other hand, there are less high-quality libraries in Go than in C++ or in JS. That may be the most limiting factor.

martijn_himself 11y ago
I just have to say this is a great answer. Thanks.
mike_hearn 11y ago
Interesting fact: Unreal Engine uses a GCd heap (or used to at least) for its core game state, so that means many AAA games use GC. And you can hit 60fps with it. Their secret is they keep the game state heap really small. Like, 50 megabytes, maybe.
- pjmlp 11y ago
  They still do https://docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/Objects/Optimizations/index.html#garbagecollection https://docs.unrealengine.com/latest/INT/Programming/UnrealA...
twotwotwo 11y ago
Another weird thing is, the background collection is still using a core (plus somewhat slowing foreground code, with write barriers) when it runs. It's kinda like you have a varying amount of CPU power. One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twiddle without looking too glitchy, maybe you can figure out some way to shed work when you start to fall behind. It'd be really cool to see someone attempt a game or such in Go--boundary pushing's always fun, more so when the boundaries are recently expanded.

omginternets 11y ago

In addition to what others have said, you can relieve much of the pressure on the GC by making liberal use of `sync.Pool`.

Jach 11y ago

Lots of neat and profitable games have been made in slower languages, so you should be fine, though in some cases you might have to replicate an entire engine... Not being real familiar with Go, the thing you'll want to look out for if your game gets "big" is unpredictable GC events, more-so even than the absolute max duration of any particular GC event. If Go (or whatever else) doesn't provide enough tuning to support "soft" realtime systems, you'll end up structuring your program to allocate in pools and release all references only at certain points to try and make the GC predictable, which is a common pattern for non-GC languages in games, so you've all but lost the let-me-not-care-about-memory-management justification for the language except for the safety aspects, which don't tend to be high priority for games...

_ph_ 11y ago

It should be suitable - but whether it is depends also on your memory usage. GCs are not black boxes which magically work or not work. They do get bad reputation by people who do heap allocations without thinking about them. They key to good GC performance is about the allocation profile. GO gives you very good control about heap allocation, so it should be possible to arrange the main game loop such that no fresh heap is allocated, which also would mean that the GC does not run. The GO GC runs when, the allocated heap grow to a set multiple (by default 2x) of the heap size after the last GC run. Adjusting this factor to your memory usage should give you pretty good control when the GC runs and when not.

AsyncAwait 11y ago

Nim (http://nim-lang.org http://nim-lang.org), is a language in some ways filling a similar niche to Go and they are suitable for games, because you can tune or even change the GC. Not the case with Go, so may be less suitable for soft real-time like games.

blakeyrat 11y ago

There are a heck of a lot games written in C#, which is not only interpreted, but probably has a less-tuned GC. Including heavy-processors like Kerbal Space Program. If KSP works in C#, you can write a game in Go no problem.

djur 11y ago
C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.
- masklinn 11y ago
  > C# is not interpreted Unless you're asserting that e.g. Python is not interpreted; or you're using the relatively recent native toolchain, C# is interpreted. That's its original state and its widest deployment pattern.
  - gecko 11y ago
    You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted. It is true that .NET programs are traditionally distributed as CLR bytecode. This is similar to a .class file or a .pyc file. But the CLR does now, and always has, had a JIT. E.g., the first line or two of https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).aspx https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).a... , which is for .NET 1.1, which explicitly states that, even at that time, the bytecode is JITed prior to execution.
    - masklinn 11y ago
      > You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted. No and no. > But the CLR does now, and always has, had a JIT. And Python has had a JIT[0] for as long as the framework has existed. [0] https://en.wikipedia.org/wiki/Psyco https://en.wikipedia.org/wiki/Psyco now replaced by the pypy project

tossableacct11 11y ago

So I wondered that as well and did some Googling. Found a blog post by Joel Webber, who I have not heard of, but he was working on a minecraft clone and had some advice on avoiding GC and memory layout: http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go Also found an engine, Azul 3D, and they made this claim: https://azul3d.org/doc/faq.html#what-about-the-garbage-collector https://azul3d.org/doc/faq.html#what-about-the-garbage-colle... Then there is termloop, which is a terminal based engine: https://github.com/JoelOtter/termloop https://github.com/JoelOtter/termloop Fun for indie game stuff. So, yeah. There's that.