4 ms·

My understanding is that Go's ffi overhead[1] makes game development impractical at a certain level, due to the amount of opengl calls you have to make. Is thi

My understanding is that Go's ffi overhead[1] makes game development impractical at a certain level, due to the amount of opengl calls you have to make. Is this still the case? [1] https://github.com/dyu/ffi-overhead/blob/master/README.md https://github.com/dyu/ffi-overhead/blob/master/README.md

gameswithgo 9y ago
That test was using Go 1.8, did 1.9 introduce any improvement? There appear to be improvements coming for 1.10 and 1.11: https://github.com/golang/go/issues/14939 https://github.com/golang/go/issues/14939 You don't necessarily have to make a large number of calls into C per frame when using opengl though, I'm not sure it would be a deal breaker.
- gameswithgo 9y ago
  Looks like no, no substantive improvement in 1.9
- Xeoncross 9y ago
  I re-tested with 1.9 and got: # Go 500000000 in 53058 ms # C 500000000 in 1989 ms
  - gameswithgo 9y ago
    grab the 1.10 beta and try?? =)
Narishma 9y ago
Wouldn't that only be an issue for high-end AAA games though?
gameswithgo 9y ago
Just doing some napkin math. It would be about 13,000 calls into C per frame, to waste 1 ms with call overhead. 1ms would still be a lot when you only have ~16ms to work with,but I don't think even AAA games make within an order of magnitude of that many opengl calls per frame? Even writing in pure C you want to batch things as much as possible. I think typical is well under 1000 calls per frame, but I've only got experience with small hobbyist projects.
Xeoncross 9y ago
Well, see my issue: https://github.com/dyu/ffi-overhead/issues/2 https://github.com/dyu/ffi-overhead/issues/2
kqr 9y ago
Maybe if you are doing deprecated GL_BEGIN stuff -- but that is ridiculously inefficient even in languages with native bindings! I don't see how FFI overhed would be a big deal for modern GL code. Most of the bindings happen only once. Then, sure, you update some buffers and ask the shaders to draw, but the buffer updates are likely limited by available bandwidth between primary memory and GPU, and the actual drawing is done in-GPU by shaders -- the single FFI call to start that process does not seem like a big deal in comparison.

gameswithgo 9y ago

That test was using Go 1.8, did 1.9 introduce any improvement? There appear to be improvements coming for 1.10 and 1.11: https://github.com/golang/go/issues/14939 https://github.com/golang/go/issues/14939 You don't necessarily have to make a large number of calls into C per frame when using opengl though, I'm not sure it would be a deal breaker.

gameswithgo 9y ago
Looks like no, no substantive improvement in 1.9
Xeoncross 9y ago
I re-tested with 1.9 and got: # Go 500000000 in 53058 ms # C 500000000 in 1989 ms
- gameswithgo 9y ago
  grab the 1.10 beta and try?? =)

Narishma 9y ago

Wouldn't that only be an issue for high-end AAA games though?

gameswithgo 9y ago

Just doing some napkin math. It would be about 13,000 calls into C per frame, to waste 1 ms with call overhead. 1ms would still be a lot when you only have ~16ms to work with,but I don't think even AAA games make within an order of magnitude of that many opengl calls per frame? Even writing in pure C you want to batch things as much as possible. I think typical is well under 1000 calls per frame, but I've only got experience with small hobbyist projects.

Xeoncross 9y ago

Well, see my issue: https://github.com/dyu/ffi-overhead/issues/2 https://github.com/dyu/ffi-overhead/issues/2

kqr 9y ago

Maybe if you are doing deprecated GL_BEGIN stuff -- but that is ridiculously inefficient even in languages with native bindings! I don't see how FFI overhed would be a big deal for modern GL code. Most of the bindings happen only once. Then, sure, you update some buffers and ask the shaders to draw, but the buffer updates are likely limited by available bandwidth between primary memory and GPU, and the actual drawing is done in-GPU by shaders -- the single FFI call to start that process does not seem like a big deal in comparison.