6 ms·

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 developm

by qazwe 8y ago

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)

pcwalton 8y ago
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.
- ngrilly 8y ago
  > 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.
  - pcwalton 8y ago
    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.
    - dilap 8y ago
      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.
      - pcwalton 8y ago
        Note that I'm not sure how FFI calls out of Unity's VM compare to those of cgo.
        dilap 8y ago
        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...
        ngrilly 8y ago
        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?
        dilap 8y ago
        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 https://github.com/golang/go/issues/16051 these benchmarks https://github.com/dyu/ffi-overhead 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.
        ngrilly 8y ago
  - Thaxll 8y ago
    All major game engines use a custom allocator.
  - ychen306 8y ago
    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.
    - littlestymaar 8y ago
      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)
blaisio 8y ago
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.
enqk 8y ago
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.
jy3 8y ago
As previously stated, Go for video game servers feels like a no brainer.
- koffiezet 8y ago
  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...
  - pjmlp 8y ago
    A big chunck of AAA game servers is already implemented in Java, .NET, Erlang. Not all of them use C++ on the server side.
    - koffiezet 8y ago
      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...
      - pjmlp 8y ago
        Yeah, that could be the case yes.
- ralusek 8y ago
  I think it's treated as being just fine for video game servers, my assumption was that they meant for game engine development.

by qazwe 8y ago

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)

pcwalton 8y ago

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.

ngrilly 8y ago
> 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.
- pcwalton 8y ago
  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.
  - dilap 8y ago
    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.
    - pcwalton 8y ago
      Note that I'm not sure how FFI calls out of Unity's VM compare to those of cgo.
      - dilap 8y ago
        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...
        ngrilly 8y ago
        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?
        dilap 8y ago
        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 https://github.com/golang/go/issues/16051 these benchmarks https://github.com/dyu/ffi-overhead 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.
        ngrilly 8y ago
- Thaxll 8y ago
  All major game engines use a custom allocator.
- ychen306 8y ago
  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.
  - littlestymaar 8y ago
    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)

blaisio 8y ago

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.

enqk 8y ago

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.

jy3 8y ago

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

koffiezet 8y ago
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...
- pjmlp 8y ago
  A big chunck of AAA game servers is already implemented in Java, .NET, Erlang. Not all of them use C++ on the server side.
  - koffiezet 8y ago
    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...
    - pjmlp 8y ago
      Yeah, that could be the case yes.
ralusek 8y ago
I think it's treated as being just fine for video game servers, my assumption was that they meant for game engine development.