6 ms·

Performance of green threads and why it matters

56 points by rumcajz 10y ago

hellofunk 10y ago
>First of all, go() statement in Go language does parallelism in addition to simple green-threading. With all the talk about 'concurrency is not parallelism' that seems to be part of Go's DNA, I find the design decision to support both using a single statement a bit weird. Have to agree on this, and often wonder the same thing.
- themartorana 10y ago
  I'm having a hard time understanding where you would want concurrency without the benefit of parallelism where available? I also personally consider the idea of single-core concurrency as "not parallelism" to be semantics. It may not be truly parallel, but both routines are getting CPU time in the same algorithm, so, in terms of programmatic considerations, to me the two (at least with Go) are basically the same.
  - justincormack 10y ago
    So you don't need locking.
    - wyager 10y ago
      Non-parallel (perpendicular?) green threads are semantically indistinguishable from parallel green threads. If you need locks with parallelism, you need them with green threads. Any locking unique to parallelism is handled by the runtime.
  - deleted 10y ago
    [deleted]
  - cfallin 10y ago
    Concurrency implies multiple partial computations in progress, but not necessarily that they run at the same time -- some models (e.g. a single-threaded event loop, like Node's) explicitly guarantee mutual exclusion and define certain preemption points. Cooperative multitasking, single-threaded event loops, and futures/promises (when not pushed to a thread pool) are good examples. (I've also seen definitions of concurrency that do not imply the above, but I think the above definition is more in line with the distinction people try to make...)
  - barrkel 10y ago
    Concurrency models the nondeterminism of the world outside the program. Parallelism is a performance improvement, at the cost of synchronisation for shared data. The two are orthogonal. Many programs are better written using concurrent primitives; whether they are better of with parallelism is a separate optimisation subject to tradeoffs, like all optimisations. If you can live without preemption, a single threaded world is no bad thing for correctness. Everything that touches the outside world (blocks) may be a green thread switch point though, so it's no panacea. Without hardware executing code in parallel, it's not parallelism, BTW. It's not semantics; it's specific jargon that means something.
- eikenberry 10y ago
  That's because parallelism is an optimization, not a programming abstraction. You might as well ask why function calls and inlined function calls don't have different statements. They certainly can (eg. C's inline keyword) but it is not necessary nor that important to inlining as an optimization.
  - ruggeri 10y ago
    One difference is that inlining is a safe optimization in most contexts. Parallelizing a goroutine is not safe if the goroutine shares memory. Obviously that's not the default Go style, but sometimes sharing state is unavoidable. So that would be one point in favor of different syntax.
- twotwotwo 10y ago
  I like eikenberry's explanation of why in the sense of "what was the logic"; I speculated some on practical tradeoffs over on lobste.rs: https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_matters/comments/fdus6y#c_fdus6y https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_...
jeffreyrogers 10y ago
Here's a good (introductory) resource on implementing green threads: http://c9x.me/art/gthreads/intro.html http://c9x.me/art/gthreads/intro.html. It's helpful for learning how they work in practice. Are people running into performance issues with green threads in practice? It seems like they're already pretty performant, particularly if you're using them more as an abstraction for concurrency than as a way to get parallelism. There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. If you really care about performance you probably shouldn't be using green threads at all but should instead be running separate processes on dedicated cores. Green threads also have the advantage over kernel threads in that they don't require the overhead of a kernel context switch, since the context switch can be done in userspace, which requires saving much less context and also affects your caches less.
- auxym 10y ago
  Why processes vs os-level threads?
  - learc83 10y ago
    The OP said processes on dedicated cores, so I guess they meant you should use processes if you need fewer threads than you have available cores. If that is the case then processes could be faster than OS threads because you'd avoid context switches altogether. However, if your system supports pinning OS threads to processors and you limit the number of threads to the number of available processors, I can't think why that wouldn't be just as good.
- zzzcpan 10y ago
  > There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. Name at least one that cannot be solved better without them.
  - rumcajz 10y ago
    Network stacks. And pipelines in general.
zzzcpan 10y ago
There is a very big difference between implicit flow control, that you have with green threads and explicit one, that you have with "reinvented green threads", as you call them. First one will force you to think about synchronization to access your memory, but the second one - won't. It will also let you do clean cancellation, etc., that you won't be able to do with green thread. Downvote all you want.
- jcoffland 10y ago
  Go is an interesting language but the fanboys on HN tend to down vote any criticism. Same goes for the other golden child, Rust.
  - dang 10y ago
    This breaks the site guidelines by calling names ('fanboys') and complaining about downvoting. The problem with comments like this is that they degrade the discourse even if they're true. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- dang 10y ago
  > Downvote all you want. Please don't break the HN guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. We detached this subthread from https://news.ycombinator.com/item?id=11654767 https://news.ycombinator.com/item?id=11654767 and marked it off-topic.
halayli 10y ago
Goroutines use segmented stacks that allows them to grow dynamically as needed. so 4k goroutines != 4gb of ram. They currently start at 8k and grow as needed but copies are incurred to keep it contiguous. In lthread I preallocate fixed size 1mb stack but madvise after a coroutine yields if the stack shrunk. No copies are needed but it does consume the vm address space.
- ominous_prime 10y ago
  Go hasn't used segmented stacks in quite a while. Go now has 2k stacks and uses stack copying to grow.
  - deleted 10y ago
    [deleted]
bobinator606 10y ago
we built a green threads implementation for VAX/VMS in 1984 with pre-allocated stacks because performance. the key is to put guard pages in between the stacks to protect from stack overruns.

56 points by rumcajz 10y ago

>First of all, go() statement in Go language does parallelism in addition to simple green-threading. With all the talk about 'concurrency is not parallelism' that seems to be part of Go's DNA, I find the design decision to support both using a single statement a bit weird. Have to agree on this, and often wonder the same thing.

themartorana 10y ago
I'm having a hard time understanding where you would want concurrency without the benefit of parallelism where available? I also personally consider the idea of single-core concurrency as "not parallelism" to be semantics. It may not be truly parallel, but both routines are getting CPU time in the same algorithm, so, in terms of programmatic considerations, to me the two (at least with Go) are basically the same.
- justincormack 10y ago
  So you don't need locking.
  - wyager 10y ago
    Non-parallel (perpendicular?) green threads are semantically indistinguishable from parallel green threads. If you need locks with parallelism, you need them with green threads. Any locking unique to parallelism is handled by the runtime.
- deleted 10y ago
  [deleted]
- cfallin 10y ago
  Concurrency implies multiple partial computations in progress, but not necessarily that they run at the same time -- some models (e.g. a single-threaded event loop, like Node's) explicitly guarantee mutual exclusion and define certain preemption points. Cooperative multitasking, single-threaded event loops, and futures/promises (when not pushed to a thread pool) are good examples. (I've also seen definitions of concurrency that do not imply the above, but I think the above definition is more in line with the distinction people try to make...)
- barrkel 10y ago
  Concurrency models the nondeterminism of the world outside the program. Parallelism is a performance improvement, at the cost of synchronisation for shared data. The two are orthogonal. Many programs are better written using concurrent primitives; whether they are better of with parallelism is a separate optimisation subject to tradeoffs, like all optimisations. If you can live without preemption, a single threaded world is no bad thing for correctness. Everything that touches the outside world (blocks) may be a green thread switch point though, so it's no panacea. Without hardware executing code in parallel, it's not parallelism, BTW. It's not semantics; it's specific jargon that means something.
eikenberry 10y ago
That's because parallelism is an optimization, not a programming abstraction. You might as well ask why function calls and inlined function calls don't have different statements. They certainly can (eg. C's inline keyword) but it is not necessary nor that important to inlining as an optimization.
- ruggeri 10y ago
  One difference is that inlining is a safe optimization in most contexts. Parallelizing a goroutine is not safe if the goroutine shares memory. Obviously that's not the default Go style, but sometimes sharing state is unavoidable. So that would be one point in favor of different syntax.
twotwotwo 10y ago
I like eikenberry's explanation of why in the sense of "what was the logic"; I speculated some on practical tradeoffs over on lobste.rs: https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_matters/comments/fdus6y#c_fdus6y https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_...

jeffreyrogers 10y ago

Here's a good (introductory) resource on implementing green threads: http://c9x.me/art/gthreads/intro.html http://c9x.me/art/gthreads/intro.html. It's helpful for learning how they work in practice. Are people running into performance issues with green threads in practice? It seems like they're already pretty performant, particularly if you're using them more as an abstraction for concurrency than as a way to get parallelism. There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. If you really care about performance you probably shouldn't be using green threads at all but should instead be running separate processes on dedicated cores. Green threads also have the advantage over kernel threads in that they don't require the overhead of a kernel context switch, since the context switch can be done in userspace, which requires saving much less context and also affects your caches less.

auxym 10y ago
Why processes vs os-level threads?
- learc83 10y ago
  The OP said processes on dedicated cores, so I guess they meant you should use processes if you need fewer threads than you have available cores. If that is the case then processes could be faster than OS threads because you'd avoid context switches altogether. However, if your system supports pinning OS threads to processors and you limit the number of threads to the number of available processors, I can't think why that wouldn't be just as good.
zzzcpan 10y ago
> There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. Name at least one that cannot be solved better without them.
- rumcajz 10y ago
  Network stacks. And pipelines in general.

zzzcpan 10y ago

There is a very big difference between implicit flow control, that you have with green threads and explicit one, that you have with "reinvented green threads", as you call them. First one will force you to think about synchronization to access your memory, but the second one - won't. It will also let you do clean cancellation, etc., that you won't be able to do with green thread. Downvote all you want.

jcoffland 10y ago
Go is an interesting language but the fanboys on HN tend to down vote any criticism. Same goes for the other golden child, Rust.
- dang 10y ago
  This breaks the site guidelines by calling names ('fanboys') and complaining about downvoting. The problem with comments like this is that they degrade the discourse even if they're true. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
dang 10y ago
> Downvote all you want. Please don't break the HN guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. We detached this subthread from https://news.ycombinator.com/item?id=11654767 https://news.ycombinator.com/item?id=11654767 and marked it off-topic.

halayli 10y ago

Goroutines use segmented stacks that allows them to grow dynamically as needed. so 4k goroutines != 4gb of ram. They currently start at 8k and grow as needed but copies are incurred to keep it contiguous. In lthread I preallocate fixed size 1mb stack but madvise after a coroutine yields if the stack shrunk. No copies are needed but it does consume the vm address space.

ominous_prime 10y ago
Go hasn't used segmented stacks in quite a while. Go now has 2k stacks and uses stack copying to grow.
- deleted 10y ago
  [deleted]

bobinator606 10y ago

we built a green threads implementation for VAX/VMS in 1984 with pre-allocated stacks because performance. the key is to put guard pages in between the stacks to protect from stack overruns.