On Sunday, 14 March 2021 at 07:57:12 UTC+1 Jason E. Aten wrote:
> I was noodling about how to minimize the cost of crossing the CGO barrier
from Go code into C code and back.
> Then I thought, what if I look at this the other way around.
> Instead of teaching the Go compiler how to better run C code, what if a C
compiler (e.g. clang) was taught to generate code that used the Go stack
and calling conventions.
> Theoretically, the cc output "in Go convention" could be linked with Go
code without paying the CGO penalty, no?
I'm no authority here, but I believe a large (major?) part of the Cgo
overhead is caused by scheduling overhead. As I understand it, a C function
call is non-preemptible and the Go runtime don't know whether the call will
block. I believe there have been proposals to mark Cgo calls as
"non-blocking" or similar, in effect promising the runtime that the call
will return quickly enough to elide scheduling. The problem is that if a
"non-blocking" C call turns out to block, your program may deadlock.
I also think that it's been mentioned by authorities (probably Ian) that
there are still gains to be made from optimizing the existing trampolines
and calling convention adapters.
Elias
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/592f7074-962e-4ffd-8777-8644427ba3bbn%40googlegroups.com.
