On 2013-11-13 20:30, Daniel Micay wrote: > On Wed, Nov 13, 2013 at 1:48 PM, Bardur Arantsson <[email protected]> > 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. >
I haven't been following too closely, so... I'm guessing a whole-program CPS transform is out of the picture? > 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). Indeed, and abolutely correct. As long as the language semantics supports "thread-like" approach to concurrency (without shared state), you'll be golden. I think the point in the video[2] about non-blocking is bang on. In practice it's much more difficult to be *explicitly* async and it should just be delegated to the language/runtime. There are some things humans just aren't good at. Regards, _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
