[rust-dev] Why focus on single-consumer message passing?

Patrick Walton pcwalton at mozilla.com
Sun Jan 26 06:46:05 PST 2014

On 1/26/14 5:13 AM, Daniel Micay wrote:
> I think shared memory is widely applicable and easy to use too. It's
> often much harder to use message passing.

Message passing has been proven time and time again to be among the 
easiest forms of concurrency to understand and use. You don't have to 
look any further than the list of the most popular concurrent languages.

> Rust is making a lot of semantic sacrifices for the sake of
> performance. I see most of it as being under the assumption that it
> will eventually perform well rather than being based on hard numbers.

This is either:

1. An implication that we are not benchmarking, which is plainly false.

2. A denial that sometimes getting good performance requires a 
sophisticated implementation that takes time to get right. This is also 
false. Look at JavaScript engines, for example. You don't get good 
performance without at least two JITs (one non-SSA, one SSA) and 
possibly an interpreter. (And this is not because of JavaScript's 
complexity; LuaJIT's tracing is awfully complex too.) In these 
situations, the only way to know whether you're heading down the right 
path is to actually spend the time to optimize the implementation. Until 
that is done, stop energy (such as your constant stop energy against M:N 
threading) is entirely unhelpful.

> It's significantly (20-30%+)
> slower in the case where the condition variable is being hit a lot due
> to imbalance in consumption/production.

Then why not expose a work-stealing queue instead?


More information about the Rust-dev mailing list