Go "cares" because in Go it's common for a single OS thread to correspond to 25-100% of runnable goroutines.
So the accounting for "how many OS threads are available to run goroutines" tends to be fine-grained, otherwise weird failure-to-schedule bugs can occur. It's likely it could be improved, but it's not at all easy, especially if we factor in the problem of testing it, and any weird performance effects on other Go programs. On Sunday, March 14, 2021 at 10:54:43 PM UTC-4 ren...@ix.netcom.com wrote: > 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 <ia...@golang.org> wrote: > > > > On Sun, Mar 14, 2021 at 1:46 PM Robert Engels <ren...@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 <ia...@golang.org> > wrote: > >>> > >>> On Sun, Mar 14, 2021 at 12:00 PM Robert Engels <ren...@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....@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...@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...@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...@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/8dfcacd6-8132-4c87-bafc-8709874f0cabn%40googlegroups.com.
