On Wed, Nov 13, 2013 at 1:48 PM, Bardur Arantsson <s...@scientician.net> wrote: > On 2013-11-13 11:45, Daniel Micay wrote: >> Before getting right into the gritty details about why I think we should >> think > [--snip--] > > Very interesting video about the kernel (in future) perhaps interacting > more closesly with user-space about scheduling decisions and threads, > thus reducing overhead and perhaps eliminating the *need* for M:N. > > Having said that, M:N seems to work for Haskell where they recently > showed near-perfect scalability to 42 cores for a web server (beating > out nginx and apache handily, even on absolute numbers). For the life of > me I can't find the PDF/paper reference right now, but I'll try to > follow up with a proper reference. Perhaps there's some magical > properties of Haskell with make that less problematic than for Rust, but... > > Anyway, of course we all *hope* that tricks like M:N won't be necessary > in the future, but how soon can we hope that the future arrives? ;) > > Regards,
Haskell is a fully managed language with a precise garbage collector and doesn't use a traditional call stack so lightweight threads are a sunken cost. Rust tasks won't be comparably lightweight without segmented stacks and reinventing most of the standard C library like Go has to do. Go has precise garbage collector and could move to relocatable contiguous stacks in the future. It's known that M:N scheduling is a viable way of building a socket server. I'm only questioning whether it's worth making compromises for every other use case to micro-optimize context switches out of socket servers and make them scalable on platforms with poor support for the 1:1 threading model (OS X). _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
