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

[Aram Hăvărneanu <aram.h%mgk.ro@localhost>]

> 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 overhead doesn't come from the ABI translation, but it comes
from the Go runtime. If libc is not used, Go can do system calls
on Go stacks. If libc is used, Go can't do system calls on Go stack,
it needs to switch to a C-compatible stack. Before switching to a
C stack, the Go program must inform the runtime of this, then, the
runtime will take certain actions. Similarly, after return from
system call, Go will switch stacks and the runtime must be informed
again and it will take other actions.

It is this overhead in the runtime that make the Go-C bridge
relativelly slow, not the ABI translation itself.

This overhead is still pretty minor though. Its effects are usually
felt when calling high-performance user space C code, not when doing
system calls, where the  execution of the system call will usually
dwarf this overhead.

Note that the Solaris port is 95% a POSIX port. There are few Solaris
specific parts. If the Go port to NetBSD switched to libc model we
could remove a lot of code, since the Solaris code should "just
work". Same for every other Unix port really.

-- 
Aram Hăvărneanu