4 ms·

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 h

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.
- pjmlp 11y ago
  Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development. No sane game developer would use anything other than Assembly. The more things change, the more they stay the same.
  - twotwotwo 11y ago
    Wasn't to discourage at all--was trying to give my understanding (based on the design docs, talks, etc.) of what your CPU budget looks like and speculate about ways to deal. "It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.
    - pjmlp 11y ago
      That was my point as well. The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways. Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly. The compilers weren't that good generating code and they didn't want to loose the power of Assembly. Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago. We need to keep the spirit of taking things far alive, because in computing seeing is believing.

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.

pjmlp 11y ago
Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development. No sane game developer would use anything other than Assembly. The more things change, the more they stay the same.
- twotwotwo 11y ago
  Wasn't to discourage at all--was trying to give my understanding (based on the design docs, talks, etc.) of what your CPU budget looks like and speculate about ways to deal. "It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.
  - pjmlp 11y ago
    That was my point as well. The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways. Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly. The compilers weren't that good generating code and they didn't want to loose the power of Assembly. Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago. We need to keep the spirit of taking things far alive, because in computing seeing is believing.