8 ms·

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 s

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?
  - agentS 15y ago
    > I think you should read the M:N scheduling links. I'll leave it at that. Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads, so Go isn't exactly alone in this regard. Even Twisted, and Node use a weaker form of this, where everything runs on one thread. > Read the comment at the top. Hardly trivial. First, the comment's meant for language implementors. You don't need to read this comment to be able to do C interop in Go. Second, this isn't even that complicated... did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript...
    - 0xABADC0DA 15y ago
      > Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. The links for Ingo and Ulrich worked, these are enough of an indictment of M:N threading. What's changed in the last decade? OS gurus tried M:N threading and it failed. Java tried 'green threads' and it failed, and now Google Go devs are trying the same thing. Guess what's going to happen? > Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads Erlang was written in Prolog and the desktop VM was single-process until several years ago. That's not a good example implementation to base a design on for a new language. Meanwhile the good things like separate heap/gc per 'thread' weren't copied. /forehead > did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. I don't think I know of another language that locks another thread, transfers control to it, and then finally calls the C function. That's crazy talk -- why they say "down the rabbit whole" in that comment. Most languages do some type checking (for instance error on passing a BigInteger > uint32_t to a function taking uint32_t) and marshall the arguments then call the C function. Maybe they need to pin an object or convert it to a C-friendly form (make a struct that describes properties of the object). But yeah in general the C interop is very simple in most languages. > And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript... I don't say "Google Dart" because Dart isn't an unsearchable, ambiguous name for a programming language. I do say "Apple Blocks" because 'blocks' is unsearchable in the context of programming languages. You can't blame me for Google choosing a terrible name. Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted?
- smeg 15y ago
  Does anyone know why the Go runtime is written in C? The FAQ says it is to get around bootstrapping, but that does not seem obvious, as the Go compiler (6g) is written in C, so why cant the runtime be written in Go and compiled with the rest of the Go library? Also, is the incompatibility between Go and C just due to the segmented stacks in Go? What about function call conventions? Anything else?
  - msbarnett 15y ago
    If the runtime were written in Go, what would the runtime's runtime be?
    - smeg 15y ago
      Well given that the current runtime (written in C) doesn't have a runtime, I would assume there wouldn't be one, as Go compiles down to native code just like C does, using the same toolchain (6c/g -> 6a -> 6l). My current guesses are: 1) Performance 2) The need to call assembly code easily
      - msbarnett 15y ago
        C is capable of running without a runtime, but Go isn't. This has nothing to do with compiling down to native code and everything to do with the language semantics.
        smeg 15y ago
        Right, so native code generated by Go probably needs some kind of runtime initialization before it can even start executing.
        msbarnett 15y ago
        Among other things which aren't expressible in Go, that's part of it. You could do those bits in Assembler and the rest in Go if you really wanted to stay out of C, but the net effect is just that the language runtime becomes harder to port to new platforms.

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?
- agentS 15y ago
  > I think you should read the M:N scheduling links. I'll leave it at that. Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads, so Go isn't exactly alone in this regard. Even Twisted, and Node use a weaker form of this, where everything runs on one thread. > Read the comment at the top. Hardly trivial. First, the comment's meant for language implementors. You don't need to read this comment to be able to do C interop in Go. Second, this isn't even that complicated... did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript...
  - 0xABADC0DA 15y ago
    > Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. The links for Ingo and Ulrich worked, these are enough of an indictment of M:N threading. What's changed in the last decade? OS gurus tried M:N threading and it failed. Java tried 'green threads' and it failed, and now Google Go devs are trying the same thing. Guess what's going to happen? > Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads Erlang was written in Prolog and the desktop VM was single-process until several years ago. That's not a good example implementation to base a design on for a new language. Meanwhile the good things like separate heap/gc per 'thread' weren't copied. /forehead > did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. I don't think I know of another language that locks another thread, transfers control to it, and then finally calls the C function. That's crazy talk -- why they say "down the rabbit whole" in that comment. Most languages do some type checking (for instance error on passing a BigInteger > uint32_t to a function taking uint32_t) and marshall the arguments then call the C function. Maybe they need to pin an object or convert it to a C-friendly form (make a struct that describes properties of the object). But yeah in general the C interop is very simple in most languages. > And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript... I don't say "Google Dart" because Dart isn't an unsearchable, ambiguous name for a programming language. I do say "Apple Blocks" because 'blocks' is unsearchable in the context of programming languages. You can't blame me for Google choosing a terrible name. Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted?
smeg 15y ago
Does anyone know why the Go runtime is written in C? The FAQ says it is to get around bootstrapping, but that does not seem obvious, as the Go compiler (6g) is written in C, so why cant the runtime be written in Go and compiled with the rest of the Go library? Also, is the incompatibility between Go and C just due to the segmented stacks in Go? What about function call conventions? Anything else?
- msbarnett 15y ago
  If the runtime were written in Go, what would the runtime's runtime be?
  - smeg 15y ago
    Well given that the current runtime (written in C) doesn't have a runtime, I would assume there wouldn't be one, as Go compiles down to native code just like C does, using the same toolchain (6c/g -> 6a -> 6l). My current guesses are: 1) Performance 2) The need to call assembly code easily
    - msbarnett 15y ago
      C is capable of running without a runtime, but Go isn't. This has nothing to do with compiling down to native code and everything to do with the language semantics.
      - smeg 15y ago
        Right, so native code generated by Go probably needs some kind of runtime initialization before it can even start executing.
        msbarnett 15y ago
        Among other things which aren't expressible in Go, that's part of it. You could do those bits in Assembler and the rest in Go if you really wanted to stay out of C, but the net effect is just that the language runtime becomes harder to port to new platforms.