Performance of syscall calls vs. CGO

1,063 views
Skip to first unread message

Sean

unread,
Jan 20, 2022, 5:54:26 AM1/20/22
to golang-nuts
Hi groups,
I know CGO is not performing well in Golang at the moment.
If we use a dll will this performance issue decrease?
If I do the cgo calls with syscall, will there be no performance improvements?
When I think about it, Golang always has to make syscall calls on the os it's running on. For example, in Windows, the net package has to talk to the socket api of Windows.
My assumptions are that syscall should be better than Cgo.
If syscall calls are no different from Cgo, how does Golang build this performance in the core library?

Ian Lance Taylor

unread,
Jan 20, 2022, 3:26:00 PM1/20/22
to Sean, golang-nuts
On Thu, Jan 20, 2022 at 2:54 AM Sean <s.tolst...@gmail.com> wrote:
>
> I know CGO is not performing well in Golang at the moment.

That is true, but we should quantify it. The last time I tested it, a
cgo call took about 10 times as long as an ordinary function call. So
that is pretty bad if you are calling a tiny function, but it doesn't
really matter if you are calling a function that does I/O.

> If we use a dll will this performance issue decrease?

I don't know but I don't think so.

> If I do the cgo calls with syscall, will there be no performance improvements?

I haven't measured but I don't see why using the syscall package would
be any faster.

> When I think about it, Golang always has to make syscall calls on the os it's running on. For example, in Windows, the net package has to talk to the socket api of Windows.
> My assumptions are that syscall should be better than Cgo.
> If syscall calls are no different from Cgo, how does Golang build this performance in the core library?

The Go runtime has two advantages. First, it can make the call
directly in the system ABI rather than having to translate from the Go
ABI to the system ABI. Second, it can know that certain system calls
can never block, and can use that to optimize the way that they are
handled.

Also, of course, system calls by their nature tend to be a bit slow,
so the overhead is less important. As mentioned above, the overhead
of a cgo call is most important when calling a small C function. Most
system calls are not small.

Ian

Sean

unread,
Jan 21, 2022, 5:06:12 AM1/21/22
to golan...@googlegroups.com
Hello Ian,

Thank you for the answer.

I'm currently using Cgo heavily for a game. But microseconds don't
matter to me. The calls must not exceed milliseconds, and it all depends
on the C api I wrote.
I'm currently in testing and development, there doesn't seem to be a
problem now but I don't know what to do if Cgo in production will be a
problem for me.
Dropt this wonderful std and switching to C++ will be a nightmare for me.

I'm trying some untested things in the Golang world.

Hopefully, CFFI performance will eventually get on the Golang team's
radar and improve.

Ian Lance Taylor

unread,
Jan 21, 2022, 2:03:58 PM1/21/22
to Sean, golan...@googlegroups.com
On Fri, Jan 21, 2022 at 2:06 AM Sean <s.tolst...@gmail.com> wrote:
>
> I'm currently using Cgo heavily for a game. But microseconds don't
> matter to me. The calls must not exceed milliseconds, and it all depends
> on the C api I wrote.
> I'm currently in testing and development, there doesn't seem to be a
> problem now but I don't know what to do if Cgo in production will be a
> problem for me.
> Dropt this wonderful std and switching to C++ will be a nightmare for me.
>
> I'm trying some untested things in the Golang world.
>
> Hopefully, CFFI performance will eventually get on the Golang team's
> radar and improve.

It's on our radar but it's a hard problem.

Ian
> --
> 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/7c15358f-f906-a693-6df4-de434915fa17%40gmail.com.

twp...@gmail.com

unread,
Jan 23, 2022, 6:05:45 PM1/23/22
to golang-nuts
Two tips from writing github.com/twpayne/go-geos (Go bindings for the popular GEOS geometry library), where I also encountered performance problems with cgo when calling small C functions:

1. Make each cgo call do more by moving common combinations of functions in to C, i.e. use a higher-level API.

Example: this function moves a for loop over an element lookup function from Go to C. In this particular case, this saves hundreds or thousands of cgo calls.

2. Eliminate cgo calls where possible.

Example: this function copies commonly-used data from C into a Go struct (i.e. caches them in Go) so cgo calls are not required are not required to retrieve those properties.

Regards,
Tom

Reply all
Reply to author
Forward
0 new messages