Function call intensity seems directly addressed by a tree or DAG like
chain of command buffers, not necessarily a full scene graph (with logic
and selection) but a call at the top and traverse tool to let you make just
a few cgo transitions to c per frame.
I’ve done this several ways myself
Thanks for reply, Ian
To clear up, by safety I only mean presence of stack guards or, more generally,
means of ensuring the program doesn't silently end up writing past the stack.
>From this I take my next step will be to make something between systemstack and
asmcgocall so that I still run
On Wed, Apr 29, 2020 at 12:45 PM wrote:
>
> 1) I have heard gccgo can call C much quicker than the standard go
> implementation can. If this statement is true, why is that?
It's because gccgo uses the C calling convention. So you can use a
magic //go:linkname comment to rename a Go function
I am interested in having less overhead for Go-C-Go roundtrips, for C
programs that I know (or at least am very much sure) will behave, for
most part, similar to non-preemptible (as in prior to Go 1.14) loops
in Go. Concretely, I have a self-imposed exercise of making a
frankenprogram that talks
