8 ms·

> and the times you find yourself "at the mercy" of the garbage collector is pretty damn frustrating. You're still at the mercy of the malloc implementation. I

• Rusky 7y ago
  That's true, and it's why the alternative to GC is generally not "malloc and free" or "RAII" but "custom allocators." Games are very friendly to that approach- with a bit of thought you can use arenas and object pools to cover 99% of what you need, and cut out all of the failure modes of a general purpose GC or malloc implementation.
  • xyproto 7y ago
    Interestingly, it's fully possible to disable the automatic garbage collection in Go to achieve this. Disable the garbage collector: debug.SetGCPercent(-1) Trigger garbage collection: runtime.GC() It is also possible to allocate a large block of memory and then manage it yourself.
    • majewsky 7y ago
      > It is also possible to allocate a large block of memory and then manage it yourself. At which point you're mostly just writing C in Go.
      • pm90 7y ago
        Actually you're not. I would very much prefer a stripped down version of Go used for these situations rather than throwing more C at it. The main benefits of using Go are not the garbage collection, its the tooling, the readability (and thus maintainability) of the code base, the large number of folks who are versatile in using it.
        • metiscus 7y ago
          Are you saying that there are more go developers than c developers? Is there a user survey that shows such things? I'm curious what the ratio is.
          • rdbell 7y ago
            I'd be willing to wager that C programmers would be more comfortable working with a Golang codebase than Golang programmers would be working with a C codebase. There may be more "C programmers" by number but a Golang codebase is going to be more accessible to a wider pool of applicants.
            • weberc2 7y ago
              In my experience it takes a few days for a moderate programmer to come up to speed on Go, whereas it takes several months for C. You need to hire C programmers for a C position, you can hire any programmers for a Go position.
              • cozzyd 7y ago
                If they don't already know C though, how well will they cope with manual memory management?
                • weberc2 7y ago
                  It will be a learning curve, but a much, much smaller one than learning C.
                  • kerkeslager 7y ago
                    But the entire point of this line of questioning is that there are more programmers who already know C.
                • nicoburns 7y ago
                  How do people learn C without knowing about manual memory management? They learn about it as they learn the language. This can be done in any language that allows for manual memory management (and most have much better safeguards and documentation than C, which has a million ways to shoot yourself in the foot)
      • weberc2 7y ago
        You’re writing in a much improved C. Strong type system (including closures/interfaces/arrays/slices/maps), sane build tooling (including dead simple cross compilation), no null-terminated strings, solid standard library, portability, top notch parallelism/concurrency implementation, memory safety (with far fewer caveats, anyway), etc. Go has it’s own issues and C is still better for many things, but “Go with manually-triggered GC” is still far better than C for 99.9% of use cases.
        • bufo 7y ago
          Go’s compiler is not at all optimized for generating fast floating point instructions like AVX and its very cumbersome to add any kind of intrinsics. This might not matter for light games but an issue when you want to simply switch to wide floating point operations to optimize some math.
          • weberc2 7y ago
            Yeah, C compilers optimize much more than Go compilers. Performance is C’s most noteworthy advantage over Go.
            • xyproto 7y ago
              GCC can compile both C and Go. I searched for benchmarks but found none for GCC 9 that compares the performance of C and Go. Do you have any sources on this?
              • weberc2 7y ago
                I don’t have a source, but it’s common knowledge in the Go community. Not sure how GCC works, but it definitely produces slower binaries than gc (the standard Go compiler). There are probably some benchmarks where this is not the case, but the general rule is that gcc is slower. gc purposefully doesn’t optimize as aggressively in order to keep compile times low. Personally I would love for a —release mode that had longer compile times in exchange for C-like performance, but I use Python by day (about 3 orders of magnitude slower than C) so I’d be happy to have speeds that were half as fast C. :)
    • Insanity 7y ago
      And not to forget that using Go correctly you'd end up doing mostly stack pushes and pops
    • littlestymaar 7y ago
      Due the low throughput of Go's GC (which trades a lot of it in favor of short pause duration), you risk running out if memory if you have a lot of allocations and you don't run your GC enough times.
      • xyproto 7y ago
        For a computer game, if you start out by allocating a large block of memory, then manage it yourself, I don't see how this would be a problem.
        • littlestymaar 7y ago
          You're not using the GC at all then. Why use Go (and praise its GC) in that case?
          • Skunkleton 7y ago
            For the joy of getting the round peg through the square hole of course.
          • xyproto 7y ago
            Go has many advantages over C that are not related to GC.
            • takeda 7y ago
              Go was pushed as a C replacement, but very few C programmers switched to it, it seems like it took hearts of some of Python, Ruby, Java etc programmers.
              • freyr 7y ago
                Nonetheless, Go has many advantages over C that are not related to GC.
                • 7y ago
• Gene_Parmesan 7y ago
  Which is why you generally almost never use the standard malloc to do your piecemeal allocations. A fair number of codebases I've seen allocate their big memory pools at startup, and then have custom allocators which provide memory for (often little-'o') objects out of that pool. You really aren't continually asking the OS for memory on the heap. In fact, doing that is often a really bad idea in general because of the extreme importance of cache effects. In a high-performance game engine, you need to have a fine degree of control over where your game objects get placed, because you need to ensure your iterations are blazingly fast.
  • mlthoughts2018 7y ago
    Doesn’t this just change semantics? Whatever custom handlers you wrote for manipulating that big chunk of memory are now the garbage collector. You’re just asking for finer grained control than what the native garbage collection implementation supports, but you are not omitting garbage collection. Ostensibly you could do the exact same thing in e.g. Python if you wanted, by disabling with the gc module and just writing custom allocation and cleanup in e.g. Cython. Probably similar in many different managed environment languages.
    • mntmoss 7y ago
      The semantics matter. A lot of game engines use a mark-and-release per-frame allocation buffer. It is temporary throwaway data for that frame's computation. It does not get tracked or freed piecemeal - it gets blown away. Garbage collection emulates the intent of this method with generational collection strategies, but it has to use a heuristic to do so. And you can optimize your code to behave very similarly within a GC, but the UI to the strategy is full of workarounds. It is more invasive to your code than applying an actual manual allocator.
      • PrototypeNM1 7y ago
        > A lot of game engines use a mark-and-release per-frame allocation buffer. I've heard of this concept but a search for "mark-and-release per-frame allocation buffer" returned this thread. Is there something else I could search?