3 ms·
Go will likely eventually have a GC that will not be that terrible. However, right now it's a simple parallel mark & sweep. If you allocate more than a 1000 obj
by Tuna-Fish 14y ago
Go will likely eventually have a GC that will not be that terrible. However, right now it's a simple parallel mark & sweep. If you allocate more than a 1000 objects, and do any allocation during simulation, there will be very noticeable GC pauses. The current Go GC is not anywhere near the capability of C# or Java GC, and would not be suitable for minecraft-level games.
> Overall I think (read guess) that unless you are doing some sort of physics simulation, typical game logic requires relatively little cpu power and for the graphics there is hardware acceleration doing the heavy lifting.
Well, it of course depends on the game. AAA games spend all the CPU budget allocated to them.
- gillianseed 14y agoI realize that it doesn't compare to Java's GC (which is likely state-of-the-art) but is it really terrible? Granted I haven't used Go myself (leaning towards Rust) but I've read that Go is already being employed in production scenarios with good results.
- Tuna-Fish 14y agoIt's perfectly passable for web serving and other such high-latency tasks. In a GC, the goals of throughput and latency are diametrically opposed -- optimizing for one makes the other worse. The present simplistic GC is a typical throughput-oriented design.
- gillianseed 14y agoI just remembered these (I knew I'd seen some game examples in Go): http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=iMMbf6SRb9Q which are game examples as part of a game engine framework written in Go, seems to move smoothly with lots of objects including 2d physics.