A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games?
EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).
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.
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.
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.
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.
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.
It all depends on which games people intend to write.
Apparently younger generations are unaware that C was seen as a managed language in the 80's and early 90's, with compilers not generating good enough code for game development.
In the 90's I have seen lots of Turbo Pascal and C code where the functions where plain wrappers for inline Assembly.
So unless you intend to write Crysis in Go, there are lots of games you can write with it.
Lots of neat and profitable games have been made in slower languages, so you should be fine, though in some cases you might have to replicate an entire engine... Not being real familiar with Go, the thing you'll want to look out for if your game gets "big" is unpredictable GC events, more-so even than the absolute max duration of any particular GC event. If Go (or whatever else) doesn't provide enough tuning to support "soft" realtime systems, you'll end up structuring your program to allocate in pools and release all references only at certain points to try and make the GC predictable, which is a common pattern for non-GC languages in games, so you've all but lost the let-me-not-care-about-memory-management justification for the language except for the safety aspects, which don't tend to be high priority for games...
It's a voxel game based on OpenGL. It implements much of vanilla minecraft. Annecdotally, I'd say it performs much better for me than minecraft itself does, at longer view distances, and with essentially no observable GC pauses (of which minecraft suffers quite visibly). Also, a stabler heap size, etc.
The capabilities are definitely there.
I'm spending some of my weekend moments playing around with more GL stuff based on what I've learned from reading this project, and it's quite fun. Build times are right up there where you'd expect, too -- seconds or less! (The first build takes a few moments for running gcc for the c bindings to GL, but after that, those cache nicely.) A 1-second turnaround for recompiling a whole game is an incredible breath of fresh air.
And of course, I shipped my demo game to a friend on a mac the same day I started writing. I'm on a linux. Not bad.
I can't access that link at the moment but I will have a look at it, thank you. I had exactly the same idea- to play around with bindings to OpenGL and build some demos.
To be honest, for 60fps, and now with VR - 120fps and more - it won't be good enough. But... I could be wrong... Lots of games do have additional scripting languages (.gsc in COD games, lua in others, etc., etc.) - these all have garbage collectors. The key to control that is checking your high watermarks (while playing the level), and doing incremental GC.
Whether you can write the whole game in it - I don't know, but it'll be pretty good for tools/editors/pipeline/etc.
yes and no, while the previous GC pauses wouldn't have really affected anything the size of a hobby game, the improvements are welcome. The bigger problem with Go regarding game development is operator overloading and interfacing with C, the latter being a pain when it comes to memory management.
Would these GC improvements put Golang in the same league as C# (which is widely used for game development e.g. Unity3D, the .NET runtime has a GC) or can these comparisons not be made?
As heads up when talking about Unity3D, please be aware of the pre-historic .NET runtime they still are shipping versus what Xamarin and Microsoft deliver.
So always take the JIT/GC complains in Unity3D context with that caveat in mind.
Thanks. Whilst I was aware that Unity3D was shipping with an ancient version of Mono (and more or less consequently with an ancient version of C#), I wasn't aware there were a lot of JIT/GC related complaints against it.
On one side they did a great job increasing the visibility of C# among game developers, which tend to only switch languages when the OS and console SDKs push them to do so.
On the other hand, they spread the feeling that C# is bad for game development among developers that don't understand "language != implementation" and take their Unity's experience as how C# implementations performs in general.
However I also should say that they are aware of it and planing to improve the situation after their IL2CPP compiler stabilizes.
Found a blog post by Joel Webber, who I have not heard of, but he was working on a minecraft clone and had some advice on avoiding GC and memory layout:
Nim (http://nim-lang.org), is a language in some ways filling a similar niche to Go and they are suitable for games, because you can tune or even change the GC. Not the case with Go, so may be less suitable for soft real-time like games.
It should be suitable - but whether it is depends also on your memory usage. GCs are not black boxes which magically work or not work. They do get bad reputation by people who do heap allocations without thinking about them.
They key to good GC performance is about the allocation profile. GO gives you very good control about heap allocation, so it should be possible to arrange the main game loop such that no fresh heap is allocated, which also would mean that the GC does not run. The GO GC runs when, the allocated heap grow to a set multiple (by default 2x) of the heap size after the last GC run. Adjusting this factor to your memory usage should give you pretty good control when the GC runs and when not.
There are a heck of a lot games written in C#, which is not only interpreted, but probably has a less-tuned GC. Including heavy-processors like Kerbal Space Program.
If KSP works in C#, you can write a game in Go no problem.
C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.
Unless you're asserting that e.g. Python is not interpreted; or you're using the relatively recent native toolchain, C# is interpreted. That's its original state and its widest deployment pattern.
You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted.
It is true that .NET programs are traditionally distributed as CLR bytecode. This is similar to a .class file or a .pyc file. But the CLR does now, and always has, had a JIT. E.g., the first line or two of https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).a... , which is for .NET 1.1, which explicitly states that, even at that time, the bytecode is JITed prior to execution.
.NET is JIT'd in its most popular form, the .NET Framework.
Python is interpreted in what was its most popular form, but may not be now, CPython.
This is using the definition of a JIT as an execution engine which takes in some form of bytecode and, at runtime, emits architecture-specific assembly code to a page, marks that page executable, and changes the IP to that page.
If CPython executes in that manner then I'm mistaken about CPython's execution engine and would also consider CPython to be a JIT.
- JIT and AOT compilation via NGEN up to .NET 4.5.2
- Starting with .NET 4.6, RyuJIT which uses the Visual C++ backend and exposes SIMD support to .NET languages
- When targeting Windows 8 and 8.1, AOT compilation to native code in a format called MDIL. Basically requires dynamic linking on device, everything else will be native code already
- When targeting Window 10 store applications onwards, AOT compilation to static executables
- .NET Compact Framework also always JITs
- .NET Micro Framework is the only one that does interpret MSIL
Also Microsoft .NET JIT compilers, with the exception of the .NET Micro Framework always jit the code, there is no threshold to trigger it like on most JVMs.
EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).