5 ms·

I worked as a games programmer for 8 years in C/C++, and spent an accumulated 2 years just doing optimisation, during the time of 6th and 7th generation console

I worked as a games programmer for 8 years in C/C++, and spent an accumulated 2 years just doing optimisation, during the time of 6th and 7th generation consoles. Freeing resources in a deterministic manner is important for the following reasons: FRAME RATE: having a GC collect at random frames makes for jerky rendering SPEED: Object pools allow reuse of objects without allocing/deallocing, and can be a cache-aligned array-of-structs. Structs-of-arrays can be used for batch processing large volumes of primitives. https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA RELIABILITY: This is probably applicable to the embedded realm too, but if you can't rely on virtual memory (because the console's OS/CPU doesn't support it, or once again you don't want the speed impact) then you need to be sure that allocations always succeed from a fixed pool of memory. Pre-allocated object pools, memory arenas, ring buffers etc. are a few of ways to ensure this. There's probably a lot more, but those are the reasons that jump out at me.

zemo 7y ago
you can turn off the gc in Go and run it manually. you can also write cache-aligned arrays of structs in Go if you want to. you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities.
- inimino 7y ago
  Why pick a language that has a feature you need to immediately turn off? Some people probably want to, but ... why?
  - vnorilo 7y ago
    Many programmers are very emotional about their language of choice, especially if it is their only one.
  - fileeditview 7y ago
    I guess you use every feature (insert any language here) offers for every program you write with it? The answer to your question is probably: because they like the language, are productive in it, know the libraries and the feature can be turned off so it's an option.
    - inimino 7y ago
      If I consistently don't use all the features, I pretty quickly start looking at simpler languages.
- h0l0cube 7y ago
  >you can turn off the gc in Go and run it manually And if you run the GC manually, you really don't know how long it will take - read: determinism. > you can also write cache-aligned arrays of structs in Go if you want to Wasn't this thread about why people don't use GC, not about go? I don't remember. If you're using an object pool, you're dodging garbage collection, as you don't need to deallocate from that pool, you could just maintain a free-list. > you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities To take it further, you could just allocate one large chunk of memory from a garbage collected allocator and use a custom allocator - you can do this with any language. But you're not using the GC then.
- gameswithgo 7y ago
  The existence of a GC, even when it can be turned off, does preclude a great many other possibilities, in practice. One issue which is nearly universe, and extra bad in Go, is the extra cost of FFI with C libs, which is necessary in games to talk to opengl, or sdl2, or similar. If you aren't going to use the GC, then you open up a lot of other performance opportunities by just using a language that didn't have one in the first place.

zemo 7y ago

you can turn off the gc in Go and run it manually. you can also write cache-aligned arrays of structs in Go if you want to. you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities.

inimino 7y ago
Why pick a language that has a feature you need to immediately turn off? Some people probably want to, but ... why?
- vnorilo 7y ago
  Many programmers are very emotional about their language of choice, especially if it is their only one.
- fileeditview 7y ago
  I guess you use every feature (insert any language here) offers for every program you write with it? The answer to your question is probably: because they like the language, are productive in it, know the libraries and the feature can be turned off so it's an option.
  - inimino 7y ago
    If I consistently don't use all the features, I pretty quickly start looking at simpler languages.
h0l0cube 7y ago
>you can turn off the gc in Go and run it manually And if you run the GC manually, you really don't know how long it will take - read: determinism. > you can also write cache-aligned arrays of structs in Go if you want to Wasn't this thread about why people don't use GC, not about go? I don't remember. If you're using an object pool, you're dodging garbage collection, as you don't need to deallocate from that pool, you could just maintain a free-list. > you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities To take it further, you could just allocate one large chunk of memory from a garbage collected allocator and use a custom allocator - you can do this with any language. But you're not using the GC then.
gameswithgo 7y ago
The existence of a GC, even when it can be turned off, does preclude a great many other possibilities, in practice. One issue which is nearly universe, and extra bad in Go, is the extra cost of FFI with C libs, which is necessary in games to talk to opengl, or sdl2, or similar. If you aren't going to use the GC, then you open up a lot of other performance opportunities by just using a language that didn't have one in the first place.