Re: [go-nuts] Safe ways to call C with less overhead
155 views
Skip to first unread message
Ian Lance Taylor
Apr 29, 2020, 8:17:47 PM4/29/20
to nano...@gmail.com, golang-nuts
On Wed, Apr 29, 2020 at 12:45 PM <nano...@gmail.com> 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 declaration to a C
function, and then just call it. This is completely unsafe, because
if the C function blocks or misuses pointers your program will crash
horribly. But it is fast.
> 2) How could a systemstack-like function but which can be friends with
> preemption mechanism of Go 1.14 be achieved?
That is basically a cgo call: a preemption friendly switch to the system stack.
Ian
>
> 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 declaration to a C
function, and then just call it. This is completely unsafe, because
if the C function blocks or misuses pointers your program will crash
horribly. But it is fast.
> 2) How could a systemstack-like function but which can be friends with
> preemption mechanism of Go 1.14 be achieved?
That is basically a cgo call: a preemption friendly switch to the system stack.
Ian
Constantine Shablya
Apr 30, 2020, 9:18:31 AM4/30/20
to Ian Lance Taylor, golan...@googlegroups.com
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 (subset of) Go while on systemstack but otherwise
it would be as if it was a Cgo call, with minor difference that aligning stack
and change of calling convention would happen at calls to C as opposed to at
asmcgocall.
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 (subset of) Go while on systemstack but otherwise
it would be as if it was a Cgo call, with minor difference that aligning stack
and change of calling convention would happen at calls to C as opposed to at
asmcgocall.
Michael Jones
Apr 30, 2020, 10:56:12 PM4/30/20
to Constantine Shablya, Ian Lance Taylor, golan...@googlegroups.com
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 (non-Go) and it works a charm.
--
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/CAEp866QQrqNUznSOFR4j_s6vW4X7ftEQVy48%3DH42UTBoe4DtXw%40mail.gmail.com.
Michael T. Jones
michae...@gmail.com
michae...@gmail.com
Reply all
Reply to author
Forward
0 new messages