Chinese Whispers in Rust
thornydev.blogspot.com
Chinese Whispers in Rust
1–10 of 47 posts
Re: Chinese Whispers in Rust
#2[deleted]
Re: Chinese Whispers in Rust
#3There was talk recently that rust had made the choice of m:n tasks and real threads configurable. Is it still using m:n tasks by default? Would be interesting to see a comparison between the two for something like this (which should of course heavily favor lightweight task model)
Re: Chinese Whispers in Rust
#4After compiling this with the latest rust built from git, I get only the "Illegal instruction" as an error message when I try to run this example.
Re: Chinese Whispers in Rust
#5See the discussion on the Rust subreddit for a more thorough discussion of the caveats in the Rust implementation:
http://www.reddit.com/r/rust/comments/1vnrp8/chinese_whisper...
The most salient quote from Daniel Micay (strncat):
"It doesn't demonstate a pattern you would use in Rust. Rust tasks aren't a substitute for generators/iterators and they're not around as a control flow feature."
Re: Chinese Whispers in Rust
#6See the discussion on the Rust subreddit for a more thorough discussion of the caveats in the Rust implementation: http://www.reddit.com/r/rust/comments/1vnrp8/chinese_whisper... The most salient quote from Daniel Micay (strncat): "It doesn't demonstate a pattern you would use in Rust. Rust tasks aren't a substitute for generators/iterators and they're not around as a control flow feature."
Sadly it seems the "solution" there is "don't do CSP in Rust".
Re: Chinese Whispers in Rust
#7See the discussion on the Rust subreddit for a more thorough discussion of the caveats in the Rust implementation: http://www.reddit.com/r/rust/comments/1vnrp8/chinese_whisper... The most salient quote from Daniel Micay (strncat): "It doesn't demonstate a pattern you would use in Rust. Rust tasks aren't a substitute for generators/iterators and they're not around as a control flow feature."
Sadly it seems the "solution" there is "don't do CSP in Rust".
Not quite. It's "don't do retarded things using CSP in Rust".
Re: Chinese Whispers in Rust
#8Earlier quoted context omitted.
Sadly it seems the "solution" there is "don't do CSP in Rust".
Not quite. It's "don't do retarded things using CSP in Rust".
Oh, come on. Not only is your comment needlessly insulting but it's completely unconstructive.
What types of CSP things should you do in Rust, then? Which should you not? Why is this code not a demonstration of a slowness in Rust but a 'bad idea'? How would you implement it in a more idiomatic manner in Rust?
Re: Chinese Whispers in Rust
#9Copying my message on Reddit here:
I profiled this and found that the vast majority of the time was spent allocating stack segments. So the basic problem is that this benchmark is simply tuned for segmented stacks. An implementation that does not use segmented stacks will do worse on this benchmark. We've rejected segmented stacks because they don't perform well in the real world (and hurt many other benchmarks, including most of the shootout), but they do make this one particular program fast.
The debate on M:N versus 1:1 threading seems irrelevant to this benchmark. In 1:1 mode we will also allocate a lot of stack space.
Channel performance is mostly irrelevant to this benchmark.
It's hard to say what the more "idiomatic" Rust version of this program would be, because this program doesn't do anything. The fastest version of this program would be println((N + 1).to_str()). :) An implementation based on libdispatch/TBB-style blocks might be faster, but it would look quite a bit different from this benchmark.
Re: Chinese Whispers in Rust
#10See the discussion on the Rust subreddit for a more thorough discussion of the caveats in the Rust implementation: http://www.reddit.com/r/rust/comments/1vnrp8/chinese_whisper... The most salient quote from Daniel Micay (strncat): "It doesn't demonstate a pattern you would use in Rust. Rust tasks aren't a substitute for generators/iterators and they're not around as a control flow feature."
Sadly it seems the "solution" there is "don't do CSP in Rust".
The solution is "don't spawn a huge number of tasks in a tight loop". Rust tasks are optimized for maximum performance once you spin them up, at the cost of some overhead once you spawn them. That was a deliberate choice, because not having segmented stacks makes many much more important things far faster, such as calling into C and performing tight sequential computations without thrashing on stack boundaries or using a garbage collector to move stacks around and rewrite all the pointers. Rust is about making costs explicit: when every function call could turn into a huge malloc(), you lose a lot of predictability over performance (and Go found this out too from what I gather).
Calling into C is a big one: we concluded it was basically impossible to make Rust calling into C as cheap as C calling into C in a segmented stack implementation. In practical usage, we found that the ability to call into C cheaply was much more important than the benefits of small stacks, which mostly help microbenchmarks like this at the expense of real-world code.