4 ms·

How hard was it tried? I imagine there's a reason that languages like Go adopted M:N threading... obviously part of the reason is that it's way more scaleable,

by tomp 7y ago

How hard was it tried? I imagine there's a reason that languages like Go adopted M:N threading... obviously part of the reason is that it's way more scaleable, but userspace threading is also supposed to be faster, as context switches don't need to switch to kernel space... were the problems tight loops (which AFAIK is also the problem in Go)? or maybe it's just so much easier / more efficient if you also have GC...

the_why_of_y 7y ago
The reason is that M:N threading inherently requires a language runtime, and the advantage of increased scalability (GHC threads use less than 1KB of memory) comes with the disadvantage that FFI calls are really quite expensive to do, because you need to move to a separate native thread in case the FFI call blocks. These languages (Erlang, Haskell, Go, ...) have no ambition to be useful for system programming; they're not intended as a replacement for C/C++ in that domain, unlike Rust.
dunkelheit 7y ago
In my opinion they tried hard enough. Here are the links to the discussions of that time if you are into that kind of thing: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... It is clear that they really wanted to make green threading work, but in the end it proved incompatible with other goals of the language. The main problem as I understand it is with the stack: you can't make the stack big from the beginning (or your threads wouldn't be lightweight anymore) so you need to grow it dynamically. If you grow it by adding new segments to the linked list, you get the "stack thrashing"/"hot split" problem: if you are unlucky and have to allocate/deallocate a segment in a tight loop the performance suffers horribly. Go solved the problem by switching to contiguous relocatable stacks: if there is not enough space in the stack, a bigger contiguous chunk of memory is allocated and old contents of the stack are copied there (a-la C++ vector). Now there is a problem with references to the stack-allocated variables - they become invalid. In go this problem is solvable because it is a managed garbage-collected language so they can simply rewrite all the references to point to the new locations but in rust it is infeasible.

by tomp 7y ago

the_why_of_y 7y ago

The reason is that M:N threading inherently requires a language runtime, and the advantage of increased scalability (GHC threads use less than 1KB of memory) comes with the disadvantage that FFI calls are really quite expensive to do, because you need to move to a separate native thread in case the FFI call blocks. These languages (Erlang, Haskell, Go, ...) have no ambition to be useful for system programming; they're not intended as a replacement for C/C++ in that domain, unlike Rust.

dunkelheit 7y ago

In my opinion they tried hard enough. Here are the links to the discussions of that time if you are into that kind of thing: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... It is clear that they really wanted to make green threading work, but in the end it proved incompatible with other goals of the language. The main problem as I understand it is with the stack: you can't make the stack big from the beginning (or your threads wouldn't be lightweight anymore) so you need to grow it dynamically. If you grow it by adding new segments to the linked list, you get the "stack thrashing"/"hot split" problem: if you are unlucky and have to allocate/deallocate a segment in a tight loop the performance suffers horribly. Go solved the problem by switching to contiguous relocatable stacks: if there is not enough space in the stack, a bigger contiguous chunk of memory is allocated and old contents of the stack are copied there (a-la C++ vector). Now there is a problem with references to the stack-allocated variables - they become invalid. In go this problem is solvable because it is a managed garbage-collected language so they can simply rewrite all the references to point to the new locations but in rust it is infeasible.