8 ms·
> Green threads didn't provide performance benefits over native threads in Rust. That's why they were removed. This seems wrong. This shouldn't be the point o
by theseoafs 11y ago
> Green threads didn't provide performance benefits over native threads in Rust. That's why they were removed.
This seems wrong. This shouldn't be the point of green threads -- green threads aren't a "faster" alternative to native threads. How would that work? How could it be the case that virtual threads implemented in user space are faster than native threads provided by the OS? I don't think anyone expects that to be true of green threads in general.
We don't have green threads as a useful abstraction because they're fast, we have them because they're flexible, and because they allow us to easily capture a lot of patterns. They let you easily and efficiently distribute work amongst multiple processors without having to think about the subtleties of the underlying threading model.
Of course, given Rust's other goals, shying away from green threads makes sense.
- viraptor 11y agoThere are some examples of speed difference at https://en.m.wikipedia.org/wiki/Green_threads https://en.m.wikipedia.org/wiki/Green_threads Basically if you have green threads with only one core, you don't need to do as much work with locking.
- saurik 11y agoThe argument here is less about the performance difference existing or not, and that the decision in question sounds to have been made due to the lack of something we care less about.
- viraptor 11y agoI was responding to the first paragraph, which is technically all about the performance differences. (it does say "How could it be the case that virtual threads implemented in user space are faster than native threads provided by the OS?") Whether that matters and is a valid decision point is a completely different question as you say.
- derefr 11y ago> Basically if you have green threads with only one core, you don't need to do as much work with locking. This is half the basis for the original design of the Erlang BEAM VM. SMP was a grudging afterthought; the original concept was that each VM "node" was a single scheduler process bound to a single core, and then you tied those nodes together into a (machine-internal) multi-core distributed system, effectively creating a set of "threads" communicating over socket-based message-passing IPC, rather than shared memory. M:N scheduling—where, critically, a task can be re-scheduled from one core to another—is a much more complex and less-predictable design, that's not always worth the trouble. For Erlang's particular use-cases, it turned out to be worth the trouble enough to justify programming it, eventually. But the SMP VM is still only built via a configure flag, rather than displacing the M:1 VM as "the" VM.
- acconsta 11y agoRust's green threading was... unusual. It attempted to abstract green and native threads into a single API, which lead to a lot of unnecessary overhead: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... Sadly, that proposal also removed concurrent IO from the standard library, and it hasn't been replaced.
- steveklabnik 11y agoIt may not be replaced in the standard library, but mio exists and is what most people use for non-blocking stuff.
- acconsta 11y ago1. Stackless coroutines will probably require help from the compiler team (hint hint). It'll be worth it! Think web frameworks with Nginx performance and Rust memory safety. 2. Documentation, stability, portability, quality. I'll keep banging that drum until there's a standard. :) 3. The Mio API is subjectively weird, but I might be missing something.
- dbaupp 11y agoThe first point has been on the radar for quite a while (i.e. years), but it's really non-trivial, and not at all necessary for the core language (hence not a priority for stability) since it's basically just some syntactic niceties over existing functionality.
- pcwalton 11y agoI'm confused. To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface. To take Go for an example, you could perfectly well write a conforming implementation of Go that used 1:1 native threading: it would just have different performance characteristics and things like LockOSThread() would become a no-op. Could you elaborate on what you consider the interface difference to be?
- sillysaurus3 11y agoThe interface is different because if you use a green thread within a GC'd language, you can do anything -- change anything, interact with anything -- and nothing will crash. No locking involved, and no hidden locking under the hood. It's not meant to be a performance boost, but a way of writing code where "might this crash?" is a question you're never bothered to ask. It's wonderfully freeing. Not true of native threads. If a goroutine were replaced with a native thread, it would swiftly crash on GC.
- theseoafs 11y agoThis is only true for n:1 green threading.
- sillysaurus3 11y agoSure. But I might write my n:1 code more quickly, robustly, and performant than your m:n code, since m:n forces the programmer to carefully worry about whether their code will break.
- theseoafs 11y agoMaybe, if my program has a lot of shared mutable state. I'm smart enough to avoid that though.
- Veedrac 11y agoWe're talking pretty explicitly about Rust, which doesn't have that problem.