There 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)
Chinese Whispers in Rust
11–20 of 47 posts
Re: Chinese Whispers in Rust
#12Your computer could be doing anything in the few seconds that your application ran. Is your blog really that worthless to you that you couldn't wait 5 minutes to establish that what you're saying holds water?
edit: okey, I need to sleep a bit better, I'm coming off bitter again :P
Re: Chinese Whispers in Rust
#13Copying 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, incl…
> including most of the shootout
I feel like this comment makes it sound like we care more about the shootout benchmarks than we actually do.Re: Chinese Whispers in Rust
#14Earlier quoted context omitted.
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 usi…
For Rust's goals, I can definitely believe that the first is true. I don't think the second claim is true at all, though. Lightweight threads have been extremely successful in Haskell, Erlang, etc, and not just on microbenchmarks.
Re: Chinese Whispers in Rust
#15Earlier quoted context omitted.
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?
I find his comment pretty spot on. If anything it was the "don't do CSP in Rust" comment that was unconstructive and passive aggresively insulting. Instead of understanding what he read and the constrains it shows, the commenter preffered to just piss on the language.
As for the example, it was obviously "retarted" or rather, contrived. I mean, heck, it's "chinese whispers" with 10000 channels, what more do you need to see that this is not a serious way of solving actual problems with CSP? It's a bloody microbenchmark, and those are rarely representative of anything.
>What types of CSP things should you do in Rust, then?
The types of CSP things that people use threads and processes for. E.g getting lots of computations going on in parallel, not incrementing tens a single int in each of thousands of "computations".
CSP and channels are meant for getting real (cpu intensive) work done. You don't just use threads (or greenthreads) "because concurrency".
That some Go programmers like to use channels as a control mechanism, doesn't mean CSP was meant for that kind of abuse. That's like using Exceptions for control flow to me.
Isn't it obvious that even in Go the times to complete this are horrible (just an order of magnitude less horrible because of different design trade-offs), and that doing the same job of 10,000 incrementings properly would complete in 1/1000 the time?
Re: Chinese Whispers in Rust
#16Re: Chinese Whispers in Rust
#17Earlier quoted context omitted.
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
#18Earlier quoted context omitted.
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?
Rudeness of the person you're replying to aside, I think it's well explained elsewhere in the thread that the Rust people have made choices that don't necessarily give great speed on pointless microbenchmarks (making a bunch of processes that do nothing) in favour of performance on CSP tasks where your CSPs actually do things.
Re: Chinese Whispers in Rust
#19I must really be sheltered because that is only the third time I've ever heard the term "Chinese Whispers" used for a game that I remembered as "Broken telephone".
Re: Chinese Whispers in Rust
#20edit
Also, you'll get flame detected soon enough once this turns into a debate about racism.