Re: [golang-dev] Re: Moving Go to a newer NetBSD ABI in the 1.13 dev cycle

[Ian Lance Taylor <iant%golang.org@localhost>]

On Fri, Mar 8, 2019 at 6:09 AM Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>
> On 08.03.2019 10:59, Martin Husemann wrote:
> > On Fri, Mar 08, 2019 at 09:49:21AM +0000, maya%netbsd.org@localhost wrote:
> >> The proposed options for this scenario (judging by the Darwin code) are:
> >> Go code -> Go ABI to C ABI translation -> syscall stub in libc -> syscall
> >>
> >> vs.
> >> Go code -> Go ABI syscall stub -> syscall
> >
> > There is missing the system call specific stuff between the first two
> > links here, and the Go-ABI-to-system-call-abi translation in the second one,
> > so it is not clear at all to me which method would perform better.
> >
> > All these layers/shims are pretty tiny, so I wouldn't be suprised if there
> > would be no measurable difference (but I'd love to see hard numbers).
> >
>
> The usage of syscall(2)/__syscall(2) might have tiny overhead on the
> kernel side when compared to direct syscalls. In the end difference is
> most likely negligible.

For the Go 1.12 release we changed Darwin from using direct system
calls to going through Darwin's libSystem.  According to
https://github.com/golang/go/issues/30497#issuecomment-468546122 the
slowdown was in the neighborhood of 20% on an I/O heavy benchmark.

Ian