Hacker News Reader

Comment by qazwe | Hacker News Reader

With all improvements to the GC, in 2018 Go is ready to develop real-time AAA games? In the past there is discussions that Go is not very well for game development. (GC latency)

View on HN

I would think the biggest barriers (no pun intended) to using Go in CPU-bound apps like games would be the lack of mature compiler optimizations, compared to GCC and LLVM. Additionally, the performance of cgo can cause problems when linking to libraries like Vulkan that can't effectively be lowered into syscalls.

I also think that throughput of memory allocation, not just latency, matters a lot more than people give it credit for.

> Additionally, the performance of cgo can cause problems when linking to libraries like Vulkan that can't effectively be lowered into syscalls.

Agreed. But you also ask for very fast memory allocation, which implies a bump allocator, which implies a copying GC, which implies pinning objects shared with C through cgo (Go's foreign function interface), which would probably make cgo even slower.

> I also think that throughput of memory allocation, not just latency, matters a lot more than people give it credit for.

At 60 fps, minimizing latency is critical. You have to optimize this first. When your longest GC pause is well below 1/60 s, then you can optimize throughput of memory allocation.

Anyway, most AAA video game engines being written in C/C++, my guess is they don't use a bump allocator, which means they do quite well with allocators like tcmalloc or jemalloc, probably by allocating as much as possible early, and using object pools.

I agree that these are all tradeoffs. My view is that languages like Rust and C++ exist for a reason, and demanding games are among the domains that they're most appropriate in. :)

Note that Unity is an existence proof that most games can get by just fine with high-level logic in GC.

And with a language that is not particularly fast. And with a GC that's way worse than what Go has.

Go would be fine for lots of game dev, imo.

Note that I'm not sure how FFI calls out of Unity's VM compare to those of cgo.

ah, good point. much faster than cgo. so probably that would kill you in go.

i wonder if it's possible to speed up ffi in go...

You wrote that Unity FFI is much faster than cgo. I'd be interested in knowing more about this. Why is it faster? Can you share a link to some reference material and/or benchmark?

good question! i'm not an expert.

my understanding is go is slow because each function call has to copy over to a bigger stack (goroutines have tiny stacks to start, and grow on demand, but c code can't do that, natch) and because it has to tell the goroutine scheduler some stuff for hazy reasons.

this github issue has a lot of interesting discussion of go ffi: https://github.com/golang/go/issues/16051

these benchmarks https://github.com/dyu/ffi-overhead seem to show that a c call via cgo will be about 14 (!) times slower than a c call from c# in mono, which itself is about 2 times slower than just a plain c call.

cgo doesn't copy the stack to a "bigger stack" when calling a C function. It just uses another stack, dedicated to cgo, and disallows passing pointers into the stack:

https://github.com/golang/go/issues/11089

So I think the slowness is caused by something else.

Thanks for sharing the benchmark.

ah, that makes more sense. thanks.

All major game engines use a custom allocator.

I want to point out that because go has value type, it's possible to implement Arena Allocators using only safe Go, which is something one might need for these kind of games.

Without generics, you'd need to implement one allocator per type you'd like to allocate … (Because just using Interface{} defeats the point of having value types in the first place)

It seems that frame rates of game monitors are pushing the boundaries of how low the latency should be. Imagine making a competitive multiplayer game design to run on 144hz or 200hz monitors.

No, Go is not (and probably never will be) a good language for writing real time programs in. It is a good language for writing video game servers though.

As previously stated, Go for video game servers feels like a no brainer.

That sounds a bit backwards, you would need to implement the network protocol twice and keep them in sync - which can be very tricky... Having a common code-base for parsing the network protocol into internal game structure objects is a huge advantage...

A big chunck of AAA game servers is already implemented in Java, .NET, Erlang.

Not all of them use C++ on the server side.

Many of them use C++ libs with language bindings for 'common' code though. And let that just be one of the weakest points of Go...

Yeah, that could be the case yes.

I think it's treated as being just fine for video game servers, my assumption was that they meant for game engine development.

Reply on news.ycombinator.com