True. I was collapsing the two because why does Go care. If the routine is in a C native call don’t switch the routine assigned to the thread. Similarly. If the thread is in C native it can’t affect stacks / heap structures - so routines that make C calls only need to ensure a C minimum stack size. The state I was referring to supports the determination of “is running native” and if so “leave it alone” until it returns to Go code. As long as the pointers passed to the C code are either native (non heap) or tracked the C code is “safe”.
So to that point, it’s confusing as to why the scheduler is the bottleneck in calling C code. > On Mar 14, 2021, at 9:38 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sun, Mar 14, 2021 at 1:46 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> 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. > > I don't mean to drag out the conversation but I'm not sure I > understand the point. I think you were the first person to mention GC > coordination. I don't think there is any GC coordination issue here. > There is a scheduler coordination issue, specifically the need to > inform Go's goroutine scheduler that the goroutine is changing > behavior. > > Ian > > >> 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/3B75BAC3-A3EF-4CF8-A21F-8620CFA11E7B%40ix.netcom.com.
