4 ms·

Does anyone know: Is there actually a better way in go? I've heard a couple of times that C Bindings in go are slow. Is this what is usually referred to?

silisili 3y ago
The cost of calling is slow. The C code itself runs at, well, C speed. So if you're writing a system in both, it's best to have the C side do a lot in each call, vs having the Go side call a lot of tiny funcs.
- kgeist 3y ago
  As far as I remember, there's a lot of machinery involved to make a C call because C doesn't know anything about Go's goroutines and their resizable stacks. So the runtime has to prepare the stack accordingly every time you make a call - and it's done on a dedicated CGO thread with a traditional stack.
Patrickmi 3y ago
That’s a misconception that cgo is slow, it’s improving and it’s not slow, when it comes to stacks, Go with its resizable stack and it’s concurrency it’s not hard to say that it’s very much Go is different from other languages. From a normal C function call that returns immediately there’s not much over head BUT when C function takes time with the runtime expecting return value, the runtime will try to align with the C stack creating a more traditional stack, I think there’s a proposal for a directive to let the compiler know there’s no need for the runtime to wait
- comex 3y ago
  Isn't it the opposite? cgo calls always have to switch to a larger stack (because there's no way to know in advance how much stack a function will use, and C functions don't support dynamic stack switching like Go functions do), so they have some fixed overhead per call. And that fixed overhead is most significant in relative terms when the call returns quickly.
  - Patrickmi 3y ago
    I stand corrected I don’t know much about Go’s runtime, it’s complicated that following it gives me headache
assbuttbuttass 3y ago
The better way is to call free manually, instead of relying on a finalizer. If you're only calling cgo in a few places, it's not too hard to check each one for memory leaks.

silisili 3y ago

The cost of calling is slow. The C code itself runs at, well, C speed. So if you're writing a system in both, it's best to have the C side do a lot in each call, vs having the Go side call a lot of tiny funcs.

kgeist 3y ago
As far as I remember, there's a lot of machinery involved to make a C call because C doesn't know anything about Go's goroutines and their resizable stacks. So the runtime has to prepare the stack accordingly every time you make a call - and it's done on a dedicated CGO thread with a traditional stack.

Patrickmi 3y ago

That’s a misconception that cgo is slow, it’s improving and it’s not slow, when it comes to stacks, Go with its resizable stack and it’s concurrency it’s not hard to say that it’s very much Go is different from other languages. From a normal C function call that returns immediately there’s not much over head BUT when C function takes time with the runtime expecting return value, the runtime will try to align with the C stack creating a more traditional stack, I think there’s a proposal for a directive to let the compiler know there’s no need for the runtime to wait

comex 3y ago
Isn't it the opposite? cgo calls always have to switch to a larger stack (because there's no way to know in advance how much stack a function will use, and C functions don't support dynamic stack switching like Go functions do), so they have some fixed overhead per call. And that fixed overhead is most significant in relative terms when the call returns quickly.
- Patrickmi 3y ago
  I stand corrected I don’t know much about Go’s runtime, it’s complicated that following it gives me headache

assbuttbuttass 3y ago

The better way is to call free manually, instead of relying on a finalizer. If you're only calling cgo in a few places, it's not too hard to check each one for memory leaks.