On 14 November 2013 23:01, Daniel Micay <danielmi...@gmail.com> wrote: > Correct, you won't get optimal performance with 1 task per > request/client across every platform. For non-socket I/O, it will be > as close as you can get to optimal on Linux except in terms of the > huge virtual memory consumption.
But one *rarely* gets an optimal performance with 1 one native task per request. As you pointed out, on Linux this is only suitable if the request is doing a lot of file IO with little computations. On Windows my impression is that UMS is really a tool that one should use if writing anything related to IO in asynchronous style is not possible due to compatibility requirements or when one need to deal with potentially long-running computations. As threads are expensive, performing applications there should use non-blocking API, not rely on UMS. Hence the introduction of the async keyword to facilitate that style of programming. > The performance with 1:1 threading and user-mode scheduling will match > M:N threading That Google talk about UMS on Linux acknowledged UMS will still not match performance of epoll-like API as while UMS eliminates scheduling cost, it does not eliminate context switching cost. Now, M:N threading on Linux also does not eliminate context-switching cost, but it can be made much smaller as with it context switches can be compiler-assisted and can take advantage of a particular language runtime. > You will get poor performance on Linux with an async/await scheme for > anything but sockets compared to the 1:1 user-mode scheduling, and > even then it's not a great match for the underlying ready-based API. ASFAICS async-style continuation code transformation precisely "a great match for the underlying ready-based API". Which brings back the initial question - should Rust offer that since it is known that on Windows it will offer optimal performance for most if not all IO and since on Linux this is optimal for socket IO. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
