6 ms·
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-
by 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 agoInterestingly, 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 agoActually 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 agoAre 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 agoI'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 agoIn 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 agoIf they don't already know C though, how well will they cope with manual memory management?
- weberc2 7y agoIt will be a learning curve, but a much, much smaller one than learning C.
- kerkeslager 7y agoBut the entire point of this line of questioning is that there are more programmers who already know C.
- nicoburns 7y agoHow 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)
- kerkeslager 7y ago
- kerkeslager 7y agoReadability is subjective. Large user base? C is number 2. Go isn't even in the top 10.[1] Tooling? C has decades of being one of the most commonly used languages, and a general culture of building on existing tools instead of jumping onto the latest hotness every few months. As a result, C has a very mature tool set. [1] https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- strken 7y agoUnfortunately the excellent standard library is a major benefit of Go, and it uses the GC, so if you set GOGC=off you're left to write your own standard library. I would also like to see a stripped-down version of Go that disables most heap allocations, but I have no idea what it would look like.
- weberc2 7y agoYou’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 agoGo’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 agoYeah, C compilers optimize much more than Go compilers. Performance is C’s most noteworthy advantage over Go.
- xyproto 7y agoGCC 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 agoI 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 agoAnd not to forget that using Go correctly you'd end up doing mostly stack pushes and pops
- littlestymaar 7y agoDue 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 agoFor 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 agoYou're not using the GC at all then. Why use Go (and praise its GC) in that case?
- Skunkleton 7y agoFor the joy of getting the round peg through the square hole of course.
- xyproto 7y agoGo has many advantages over C that are not related to GC.