4 ms·

This seems to partially explain why Go programmers prefer pure-Go libraries.

by moosingin3space 8y ago

pitaj 8y ago
Wow, why is the overhead so high for Go? Something to do with the garbage collector maybe?
- fragmede 8y ago
  > Thus, cgo has an overhead because it performs a stack switch, not thread switch. > It saves and restores all registers when C function is called, while it's not required when Go function or assembly function is called. https://stackoverflow.com/a/37962500 https://stackoverflow.com/a/37962500
- masklinn 8y ago
  Go does not use the C stack, so calling into C requires setting up a C stack, trampolining from the Go context to the C context, making the call and coming back. As a result, while cgo is easy to use: 1. calling a C function from Go is ~100 times more expensive than calling a Go function from Go — or was a few years back anyway this may have improved a bit since: https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o... 2. and using cgo has semantics impact on the entire program: https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go This is why Go libraries generally don't wrap native libraries and go software only calls into C when they really have no other choice, and/or have very "coalesced" APIs available (a single function call doing a lot of work whereas languages like Python are happy with making lots of very small calls to C). And why Go itself does not use the platform-provided standard libraries and performs syscalls directly, breaking any time those syscalls change[0] — which is not that rare because linux is the only platforms where raw syscalls are the kernel's API, on most other systems the libc is the platform's API. And even on linux it breaks from time to time[1] because Go doesn't want to link to libc but still wants to benefit from vdso[2]. [0] https://github.com/golang/go/issues/16606 https://github.com/golang/go/issues/16606 [1] https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ [2] https://twitter.com/bcantrill/status/774290166164754433?lang=en https://twitter.com/bcantrill/status/774290166164754433?lang...
nemo1618 8y ago
Personally, the overhead doesn't bother me that much; you can manage it by moving more work into C, cutting down on the number of FFI calls. What steers me away from cgo is that it complicates the build/release process and makes it harder to write cross-platform code. Go makes these things painless, so there's a strong incentive to not stray outside the Go toolchain.

This seems to partially explain why Go programmers prefer pure-Go libraries.

pitaj 8y ago

Wow, why is the overhead so high for Go? Something to do with the garbage collector maybe?

fragmede 8y ago
> Thus, cgo has an overhead because it performs a stack switch, not thread switch. > It saves and restores all registers when C function is called, while it's not required when Go function or assembly function is called. https://stackoverflow.com/a/37962500 https://stackoverflow.com/a/37962500
masklinn 8y ago
Go does not use the C stack, so calling into C requires setting up a C stack, trampolining from the Go context to the C context, making the call and coming back. As a result, while cgo is easy to use: 1. calling a C function from Go is ~100 times more expensive than calling a Go function from Go — or was a few years back anyway this may have improved a bit since: https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o... 2. and using cgo has semantics impact on the entire program: https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go This is why Go libraries generally don't wrap native libraries and go software only calls into C when they really have no other choice, and/or have very "coalesced" APIs available (a single function call doing a lot of work whereas languages like Python are happy with making lots of very small calls to C). And why Go itself does not use the platform-provided standard libraries and performs syscalls directly, breaking any time those syscalls change[0] — which is not that rare because linux is the only platforms where raw syscalls are the kernel's API, on most other systems the libc is the platform's API. And even on linux it breaks from time to time[1] because Go doesn't want to link to libc but still wants to benefit from vdso[2]. [0] https://github.com/golang/go/issues/16606 https://github.com/golang/go/issues/16606 [1] https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ [2] https://twitter.com/bcantrill/status/774290166164754433?lang=en https://twitter.com/bcantrill/status/774290166164754433?lang...

nemo1618 8y ago

Personally, the overhead doesn't bother me that much; you can manage it by moving more work into C, cutting down on the number of FFI calls. What steers me away from cgo is that it complicates the build/release process and makes it harder to write cross-platform code. Go makes these things painless, so there's a strong incentive to not stray outside the Go toolchain.