6 ms·

It's not an advantage at all. Google Go uses syscalls directly because its threads ("goroutines") were designed for a 32-bit architecture so their solution to

It's not an advantage at all. Google Go uses syscalls directly because its threads ("goroutines") were designed for a 32-bit architecture so their solution to not running out of virtual address space was to use small stacks that can grow. But that means it can't just call normal C function directly because there may not be enough stack, so they have to reinvent libc on every platform they port to. Meanwhile virtually every desktop is 64-bit and even ARMs will soon be 64-bit. Why design a new language around 32-bit computers? Good question.

nikcub 15y ago
I thought there were two implementations, a 32bit and a 64bit
javert 15y ago
Interesting. Is there a place you can point me to, to read up on this issue?
- 0xABADC0DA 15y ago
  From the horse's mouth: http://golang.org/doc/go_faq.html#goroutines http://golang.org/doc/go_faq.html#goroutines When they say "system resources" they mean stack space. It's limited in 32-bit because a stack large enough to be useful takes up too many virtual address space. For instance an 8 MiB stack takes up 1/512 of the 32-bit address space so you can only have max 512 threads, but in 64-bit you can have 33 million (current CPUs limited to 2^48 address space) So they segment the stack in Google Go to get more than some small number of threads. Even though Linux (edit: the kernel) only uses 4k or 8k per thread some OSes have severe limits, so they compound the segmented stack problem (making C interop slow and cumbersome) with userspace threading (M:N). A collection of links why that's a bad idea: http://www.kegel.com/c10k.html#1:1 http://www.kegel.com/c10k.html#1:1 Eventually they'll concede that this wasn't a good idea, but I wouldn't bet on when.
  - 4ad 15y ago
    There are many more system resources associated with threads, most of them are more important than mere virtual address space consumption, like context switch time and thread creation time. Linux doesn't use 4k or 8k stack per thread, pthreads default on Linux is 2MB. The only thing that's 4kB or 8kB is the kernel stack which doesn't have anything to do with this (the kernel stack 12kB or 24kB on Windows). You might have heard about this "grow stack on demand" thing, but every OS does it, not only Linux and it's about growing the committed memory, the virtual memory used by a stack is fixed at thread creation. Calling C code is very fast and it's trivial to do from Go, http://golang.org/doc/articles/c_go_cgo.html http://golang.org/doc/articles/c_go_cgo.html. Segmented stacks are available in some C implementations as well. It's not Google Go, it's simply Go, there's not a single Google reference on the page and that's intentional. Looking at your previous posts I see you have an obsession with Google. In short, you have absolutely no idea about what you are talking about and you spread malignant misinformation.
    - adgar 15y ago
      He's a notorious anti-Google troll on Reddit. He adds "Google" to "Go" so that his negative posts will be associated with both Google and Go.
      - X-Istence 15y ago
        There existed a programming language called Go before Google came along with their programming language also named Go. Not that anyone knew of the older Go before the whole naming debacle, but it may not just be anti-Google trolling to refer to it as Google Go. /devils advocate hat off.
        frou_dh 15y ago
        That one has a Yahoo! style exclamation point ;)
    - 0xABADC0DA 15y ago
      > There are many more system resources associated with threads, most of them are more important than mere virtual address space consumption, like context switch time and thread creation time. I think you should read the M:N scheduling links. I'll leave it at that. > Calling C code is very fast and it's trivial to do from Go, http://golang.org/doc/articles/c_go_cgo.html http://golang.org/doc/articles/c_go_cgo.html. Segmented stacks are available in some C implementations as well. http://golang.org/src/pkg/runtime/cgocall.c http://golang.org/src/pkg/runtime/cgocall.c Read the comment at the top. Hardly trivial. > It's not Google Go, it's simply Go, there's not a single Google reference on the page and that's intentional. Looking at your previous posts I see you have an obsession with Google. ... In short, you have absolutely no idea about what you are talking about and you spread malignant misinformation. Shoot the messenger. Maybe I post from a different account when I am critical of Microsoft, or Apple. Why would that matter to you?
4ad 15y ago
The disinformation in your post is mind boggling. Go was not designed for 32 bit, segmented stacks are great because of reasons that have nothing to have with address space addressability, in fact there are C implementations that use segmented stacks, segmented stacks do not preclude using the system libc, the reasons for bypassing libc were completely different, and calling C code from Go works just fine.
- 0xABADC0DA 15y ago
  Or in other words "you're wrong because I said so. upvotes please!". Thread count vs stack space is a well-known tradeoff in 32-bit. It doesn't take a rocket scientist to know this is the reason for segmented stacks in Google Go even if there's no smoking gun (wayback didn't archive the golang site for a long time due to a misconfigured robots.txt).
  - luriel 15y ago
    Given that is well known Go was developed mainly in a 64bit environment and that the 64bit compilers produce much faster code and have been much more tested than the 32bit toolchain, to the point that some people have complained that Go favours 64bit systems too much (if for no other reasons because that is what the main developers use), your whole argument is clearly nonsense, that you are a well known troll with some kind of fixation with bashing Google is just coincidence.
- chc 15y ago
  So, any hints about the real reason for passing up libc? Sounds like an interesting story.
pcwalton 15y ago
In Rust we use the system libc with segmented stacks, and we call C code by switching stacks. (This has been observed to get us into trouble with the indirect branch predictor, unfortunately, but we plan on addressing that by duplicating the stack switching stub for each C function.) Go is similar (I looked at its code when implementing some of this stuff). So it's not true that having segmented stacks undermines Go's ability to interact with C code. Note that another cool thing we can do is to statically link clang-compiled C code with Rust code and LLVM can inline your small C functions directly into your Rust functions and save you the stack switch -- this is one of the coolest things we can do with LLVM, IMHO.
- soamv 15y ago
  That's interesting. What is the cost of switching the stack when calling C code? Do you allocate a new stack every time a C function is called from Rust? If you inline a compiled C function, don't you have to do the stack switching for whatever that inlined function might call? Or do you only inline code that doesn't have any function calls?
- 0xABADC0DA 15y ago
  Ok I understand that you can switch to a larger stack to call C code, although as I said you can't "just call normal C function directly". You can even discount the cost to acquire it by having it stick with the thread using it (no locking, alloc, etc after the first use). That might be ok for Rust where many 'tasks' might be computational only and never call a C function. But with Google Go, I think they said "we want to have a million threads each reading a socket" or some other arbitrary limit which isn't possible in 32-bit using system threads (even with segmented stack). Does Rust do it's own threading, and if so what are the advantages you perceive to doing so?

nikcub 15y ago

I thought there were two implementations, a 32bit and a 64bit

javert 15y ago

Interesting. Is there a place you can point me to, to read up on this issue?

0xABADC0DA 15y ago
From the horse's mouth: http://golang.org/doc/go_faq.html#goroutines http://golang.org/doc/go_faq.html#goroutines When they say "system resources" they mean stack space. It's limited in 32-bit because a stack large enough to be useful takes up too many virtual address space. For instance an 8 MiB stack takes up 1/512 of the 32-bit address space so you can only have max 512 threads, but in 64-bit you can have 33 million (current CPUs limited to 2^48 address space) So they segment the stack in Google Go to get more than some small number of threads. Even though Linux (edit: the kernel) only uses 4k or 8k per thread some OSes have severe limits, so they compound the segmented stack problem (making C interop slow and cumbersome) with userspace threading (M:N). A collection of links why that's a bad idea: http://www.kegel.com/c10k.html#1:1 http://www.kegel.com/c10k.html#1:1 Eventually they'll concede that this wasn't a good idea, but I wouldn't bet on when.
- 4ad 15y ago
  There are many more system resources associated with threads, most of them are more important than mere virtual address space consumption, like context switch time and thread creation time. Linux doesn't use 4k or 8k stack per thread, pthreads default on Linux is 2MB. The only thing that's 4kB or 8kB is the kernel stack which doesn't have anything to do with this (the kernel stack 12kB or 24kB on Windows). You might have heard about this "grow stack on demand" thing, but every OS does it, not only Linux and it's about growing the committed memory, the virtual memory used by a stack is fixed at thread creation. Calling C code is very fast and it's trivial to do from Go, http://golang.org/doc/articles/c_go_cgo.html http://golang.org/doc/articles/c_go_cgo.html. Segmented stacks are available in some C implementations as well. It's not Google Go, it's simply Go, there's not a single Google reference on the page and that's intentional. Looking at your previous posts I see you have an obsession with Google. In short, you have absolutely no idea about what you are talking about and you spread malignant misinformation.
  - adgar 15y ago
    He's a notorious anti-Google troll on Reddit. He adds "Google" to "Go" so that his negative posts will be associated with both Google and Go.
    - X-Istence 15y ago
      There existed a programming language called Go before Google came along with their programming language also named Go. Not that anyone knew of the older Go before the whole naming debacle, but it may not just be anti-Google trolling to refer to it as Google Go. /devils advocate hat off.
      - frou_dh 15y ago
        That one has a Yahoo! style exclamation point ;)
  - 0xABADC0DA 15y ago
    > There are many more system resources associated with threads, most of them are more important than mere virtual address space consumption, like context switch time and thread creation time. I think you should read the M:N scheduling links. I'll leave it at that. > Calling C code is very fast and it's trivial to do from Go, http://golang.org/doc/articles/c_go_cgo.html http://golang.org/doc/articles/c_go_cgo.html. Segmented stacks are available in some C implementations as well. http://golang.org/src/pkg/runtime/cgocall.c http://golang.org/src/pkg/runtime/cgocall.c Read the comment at the top. Hardly trivial. > It's not Google Go, it's simply Go, there's not a single Google reference on the page and that's intentional. Looking at your previous posts I see you have an obsession with Google. ... In short, you have absolutely no idea about what you are talking about and you spread malignant misinformation. Shoot the messenger. Maybe I post from a different account when I am critical of Microsoft, or Apple. Why would that matter to you?

4ad 15y ago

The disinformation in your post is mind boggling. Go was not designed for 32 bit, segmented stacks are great because of reasons that have nothing to have with address space addressability, in fact there are C implementations that use segmented stacks, segmented stacks do not preclude using the system libc, the reasons for bypassing libc were completely different, and calling C code from Go works just fine.

0xABADC0DA 15y ago
Or in other words "you're wrong because I said so. upvotes please!". Thread count vs stack space is a well-known tradeoff in 32-bit. It doesn't take a rocket scientist to know this is the reason for segmented stacks in Google Go even if there's no smoking gun (wayback didn't archive the golang site for a long time due to a misconfigured robots.txt).
- luriel 15y ago
  Given that is well known Go was developed mainly in a 64bit environment and that the 64bit compilers produce much faster code and have been much more tested than the 32bit toolchain, to the point that some people have complained that Go favours 64bit systems too much (if for no other reasons because that is what the main developers use), your whole argument is clearly nonsense, that you are a well known troll with some kind of fixation with bashing Google is just coincidence.
chc 15y ago
So, any hints about the real reason for passing up libc? Sounds like an interesting story.

pcwalton 15y ago

In Rust we use the system libc with segmented stacks, and we call C code by switching stacks. (This has been observed to get us into trouble with the indirect branch predictor, unfortunately, but we plan on addressing that by duplicating the stack switching stub for each C function.) Go is similar (I looked at its code when implementing some of this stuff). So it's not true that having segmented stacks undermines Go's ability to interact with C code. Note that another cool thing we can do is to statically link clang-compiled C code with Rust code and LLVM can inline your small C functions directly into your Rust functions and save you the stack switch -- this is one of the coolest things we can do with LLVM, IMHO.

soamv 15y ago
That's interesting. What is the cost of switching the stack when calling C code? Do you allocate a new stack every time a C function is called from Rust? If you inline a compiled C function, don't you have to do the stack switching for whatever that inlined function might call? Or do you only inline code that doesn't have any function calls?
0xABADC0DA 15y ago
Ok I understand that you can switch to a larger stack to call C code, although as I said you can't "just call normal C function directly". You can even discount the cost to acquire it by having it stick with the thread using it (no locking, alloc, etc after the first use). That might be ok for Rust where many 'tasks' might be computational only and never call a C function. But with Google Go, I think they said "we want to have a million threads each reading a socket" or some other arbitrary limit which isn't possible in 32-bit using system threads (even with segmented stack). Does Rust do it's own threading, and if so what are the advantages you perceive to doing so?