darwin syscall performance?

[robert engels]

Hi,

While investigating the http2 issue, I saw this in the profiler: (sorry for the screenshot)

and looking at the code:

func syscall_syscall(fn, a1, a2, a3 uintptr) (r1, r2, err uintptr) {
   entersyscall()
   libcCall(unsafe.Pointer(abi.FuncPCABI0(syscall)), unsafe.Pointer(&fn))
   exitsyscall()
   return
}

This is implies that the runtime overhead to make the system call - in entersyscall() and exitsyscal() - is more than 10x the cost of doing the actual call.

Am I reading this right? If so, is there any outstanding issues to try and optimize this?

Btw, the call being performed is a simple write to a socket.

[Ian Lance Taylor]

I'm not sure I trust the profiling here: it's fairly likely that the time required by the system call itself is not being correctly attributed.  But the general idea may be true: it does take time to record in the scheduler that we are entering a system call.  This is also why cgo calls are slow.  And, in fact, on macOS system calls are essentially cgo calls, because macOS requires us to go through the C based libSystem rather than simply executing a SYSCALL or SVC instruction.

I don't know offhand whether there are any open issues for speeding up these calls, and I couldn't find any in a quick search.  People who work on the Go runtime are well aware of the problem.

Ian

[robert engels]

As another data point, I decided to test a few implementations of http2 downloads on OSX.

Using a Go server with default frame size (16k):

Go client:  900 M/s

Java client: 1300 M/s

curl: 1500 M/s

Using a Java server with default frame size (16k):

Go client: 670 M/s

Java client: 720 M/s

curl: 800 M/s

Using Go server with 256k client max frame size:

Go client: 2350 M/s

Java client: 2800 M/s

curl: unable to set option

Using Java server with 256k client max frame size:

Go client: 2900 M/s

Java client: 2800 M/s

curl: unable to set option

Clearly using a Go based server is the way to go :)

But there also seems to be an opportunity to improve the Go http2 client performance.

On Nov 10, 2021, at 8:33 PM, Ian Lance Taylor <ia...@golang.org> wrote:

On Wed, Nov 10, 2021 at 5:29 PM robert engels <ren...@ix.netcom.com> wrote:

Hi,

While investigating the http2 issue, I saw this in the profiler: (sorry for the screenshot)

<PastedGraphic-1.png>

and looking at the code:

func syscall_syscall(fn, a1, a2, a3 uintptr) (r1, r2, err uintptr) {
   entersyscall()
   libcCall(unsafe.Pointer(abi.FuncPCABI0(syscall)), unsafe.Pointer(&fn))
   exitsyscall()
   return
}

This is implies that the runtime overhead to make the system call - in entersyscall() and exitsyscal() - is more than 10x the cost of doing the actual call.

Am I reading this right? If so, is there any outstanding issues to try and optimize this?

Btw, the call being performed is a simple write to a socket.

I'm not sure I trust the profiling here: it's fairly likely that the time required by the system call itself is not being correctly attributed.  But the general idea may be true: it does take time to record in the scheduler that we are entering a system call.  This is also why cgo calls are slow.  And, in fact, on macOS system calls are essentially cgo calls, because macOS requires us to go through the C based libSystem rather than simply executing a SYSCALL or SVC instruction.

I don't know offhand whether there are any open issues for speeding up these calls, and I couldn't find any in a quick search.  People who work on the Go runtime are well aware of the 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/CAOyqgcVJqwMttzrE3GXeQf%2BC%3DKVtGFz%3DaXv%3DNXxaunWngE9L6Q%40mail.gmail.com.

[robert engels]

Sorry, I meant to send this on the http2 thread - and I also sent prematurely :(