Interesting. I have no idea how the GC would interact with "Go-aware" C code.
I suppose the hardest thing about the new compiler would be to emulate what Go does at blocking system calls to not actually block the whole process. (Notice somehow, and start a new thread; not sure if this is still true, I think I read it years ago). On Sunday, March 14, 2021 at 9:54:43 PM UTC-5 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/3aee6891-9b81-4c1d-8c8d-4043184223ecn%40googlegroups.com.
