Thank you for your detailed answer. 1. I'm convinced. I understand that I don't have to consider the difference in general.
> On Solaris there is no difference because they create threads the same way in all cases. nitpick. sys_solaris_amd64.go set stack size by itself, instead of using default one. is it intentional? 2. > You are correct that on ELF platforms using c-shared or c-archive > seems to force external linking, but just as I explained earlier > about cgo, the build mode and the link mode are more or less > conceptually orthogonal. That being said I do not know if c-shared > and c-archive can be made to work with internal linking or not, nor > what are the specific implications of that configuration. c-share and c-archive enforce external linking. https://github.com/golang/go/blob/504deee6088c2448fc3e91c94a 1ba69ec92fb7ef/src/cmd/link/internal/ld/config.go#L191-L196 I think that external linking always use runtime/cgo because of following line. https://github.com/golang/go/blob/504deee6088c2448fc3e91c94a 1ba69ec92fb7ef/src/cmd/link/internal/ld/lib.go#L459-L464 So, I still cannot find any possibility that newosproc0 will be called. Hiroshi On 17 July 2017 at 22:46, Aram Hăvărneanu <ara...@mgk.ro> wrote: > > 1. Is there any noticeable benchmark difference between internal > > linking and external linking? > > A benchmark testing what? > > > IIUC, when I use external linking, runtime/cgo is used for OS thread > > creation. In that case Go doesn't allocate the system stack itself. > > It's more complicated than that. By default, user-usage of cgo (when > *you* import "C") uses external linking, stdlib-usage of cgo (e.g. > os/user) uses internal linking, and non-cgo builds tend to use > internal linking, however the type of linking (internal or external) > is orthogonal to whether cgo (so runtime/cgo) is used or not. > > You can also use cgo with internal linking (except on systems which > don't support it), and you can use cgo with internal linking (on > system that support it). > > So your question is really about cgo, and not about linking. > > That being said, using runtime/cgo will indeed change the thread > creation method on some systems, but not on others. > > On Solaris threads are always created the same way irrespective > whether cgo is used or not. > > Plan 9 doesn't have cgo at all, so the point is moot. > > On Windows threads are created very similarly in both cgo and non-cgo > cases, but there is a slight difference. > > On these three platforms the kernel always provides the system stack > even when internal linking is used. > > On other systems like Linux and FreeBSD there indeed are fundemental > differences to how threads are created and how stacks are allocated > in the cgo and non-cgo cases. As you've surely discovered, on these > other systems (most systems, really) Go allocates the system stacks > before creating the threads, which are instructed to use this > already-created stack. > > > So, I assume there are some difference related to memory usage. > > On Solaris there is no difference because they create threads the > same way in all cases. > > On Windows, when cgo is used, the default thread stack size of 2MB > is used for the system stack. When cgo is not used the threads are > created with a 128kB stack instead. > > On other systems like Linux and FreeBSD some multiple of 8kB (usually > 1) is used for the system stacks in the non-cgo case. In the cgo > case, the default thread stack size is used (probably 2MB). I am > ignoring non-standard build modes like c-shared for this discussion. > The exact details vary in those cases but its the same fundamental > idea. > > However one must note that this is virtual memory, not physical > memory. These stacks only use address space, they only use as much > physical memory as needed, usually one or two pages of memory (a > page is usually 4kB but different from system to system), possibly > with the exception of Windows which might require the use of use > more physical memory. > > In principle, if you explicitely use cgo (make actual use of it) > you might cause more physical memory to be mapped onto your stacks, > than if you don't explicitely use cgo, but if you compare a pure > Go program that uses runtime/cgo, with the same one that doesn't > (perhaps due to changing linking method), there shouldn't be any > difference in physical memory usage to a first approximation > > > Is runtime.newosproc0 reachable? IIUC, newosproc0 is called by > > _rt0_$GOARCH_$GOOS_lib if runtime/cgo is not used. However, > > _rt0_$GOARCH_$GOOS_lib is invoked only if buildmode=c-shared or > > buildmode=c-archive. In addition, c-shared and c-archive always use > > external linking. When is newosproc0 actually called? > > You are correct that on ELF platforms using c-shared or c-archive > seems to force external linking, but just as I explained earlier > about cgo, the build mode and the link mode are more or less > conceptually orthogonal. That being said I do not know if c-shared > and c-archive can be made to work with internal linking or not, nor > what are the specific implications of that configuration. > > On Windows c-shared and c-archive don't seem to force external > linking, but I am not sure whether internal linking is supposed to > work or not. > > -- > Aram Hăvărneanu > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
