That was my point, based on Java, there is the ability to make the GC coordination extremely efficient a read and two writes per Go to C complete call trip - and this can often be eliminated in tight loops.
So if the scheduling is the source of inefficiency there are more simple ways to tackle than this proposal. > On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sun, Mar 14, 2021 at 12:00 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> Based on two decades of Java FFI - the overhead comes from type mapping not >> the housekeeping to control GC. The latter can be as simple as a volatile >> read and 2 writes per call and can usually be coalesced in tight loops. >> Since Go already has easy native C type mapping the FFi should be very >> efficient depending on types used. > > Go and Java are pretty different here. The type mapping overhead from > Go to C is effectively non-existent--or, to put it another way, it's > pushed entirely onto the programmer The GC housekeeping is, as you > say, low. The heaviest cost is the scheduling housekeeping: notifying > the scheduler that the goroutine is entering a new scheduling regime, > so that a blocking call in C does not block the entire program. A > minor cost is the change is the calling convention. > > As Jason says, if all of the C code--and I really do mean all--can be > compiled by a Go-aware C compiler, then the scheduling overhead can be > largely eliminated, and pushed into the system call interface much as > is done for Go code. But that is a heavy lift. Compiling only some > of the C code with a Go-aware C compiler seems unlikely to provide any > significant benefit. > > Ian > > > >> On Mar 14, 2021, at 11:37 AM, Jason E. Aten <j.e.a...@gmail.com> wrote: >> >> > 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. >> >> But that part would be handled by the C-compiler-that-knows-Go inserting the >> pre-emption points just like the Go compiler does into the generated code. >> Or the same checks for blocking. >> >> -- >> 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 golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%40googlegroups.com. >> >> -- >> 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 golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.com. > > -- > 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 golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVSphZ4w%2BNaCFnkHOmoZ%2BOdD-Ob3K%2BbcjVn02fivJRX%2Bg%40mail.gmail.com. -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/FE00494B-DCD8-4760-B87B-08F3DE486165%40ix.netcom.com.
