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?
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
