5 ms·

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 mos

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
        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 https://github.com/golang/go/issues/11089 So I think the slowness is caused by something else. Thanks for sharing the benchmark.
        dilap 8y ago
        ah, that makes more sense. thanks.

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
        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 https://github.com/golang/go/issues/11089 So I think the slowness is caused by something else. Thanks for sharing the benchmark.
        dilap 8y ago
        ah, that makes more sense. thanks.