3 ms·
I think one thing of note here is that the author did not want to make the program parallel. One of the benefits touted by Rust is "fearless concurrency." If th
by vkjv 11y ago
I think one thing of note here is that the author did not want to make the program parallel. One of the benefits touted by Rust is "fearless concurrency." If this feature was introduced this is where # lines or performance may have diverged.
- sitkack 11y agoParallel is of course very important. But if serial speed isn't in the same range, go parallel will be the same perf crutch as the Python folks who say drop to native. Rust programs shouldn't be parallel to beat a single threaded C++ program.
- toolz 11y ago>Rust programs shouldn't be parallel to beat a single threaded C++ program. I don't write code in either language, but as an outsider my impression is that rust was created to make programming for parallel execution, easier. If that's the case, why are we comparing a use case c++ is optimized for against a use case rust isn't optimized for?
- autoreleasepool 11y agoRust wasn't created to make programming for parallel execution "easier". What Rust does is make writing implicitly unsafe parrellel code impossible to write. This is a good thing, but is orthogonal to single threaded performance (which from what I've read, the Rust team definitely cares about).
- kzrdude 11y agoIt's absolutely intended to make it easier. Easier in the sense for example, that you can create a multithreaded program that uses stack-allocated but shared data, and you don't have to debug complex synchronization yourself. The rayon library is an exciting example of some of the possibilities http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/ http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo... Rayon, being a multithreading library, is of course itself not so trivial to write. What it lives up to is that users of rayon can use the regular rust type system rules to ensure that their use of rayon is thread safe if it compiles.
- autoreleasepool 11y agoI find rust is still a complex language. I don't find concurrency to be any easier to write using Rust over using the C++11 concurrency API, for example. I don't have much real experience with concurrent Rust applications, though. What Rust does have is that once your code compiles in safe mode you're very confident. Overall, I like the complexity and I have been enjoying my time with Rust. I began using for bare metal ARM programming. After using Rust in "no standard library mode", I'm now convinced there are no more valid reasons for using C in this century. To me, Rust is a no-brainier replacement C. It's not however, going to effect the adoption of modern C++, which has a slightly higher level niche in performance critical applications. It's the libraries that make C++ awesome, definitely not the language itself (although the core is improving).
- pcwalton 11y agoIs there a rayon replacement in C++ (lightweight tasks for parallelism with a lock-free work-stealing scheduler), other than Cilk itself, which isn't really C++?
- autoreleasepool 11y agoI have no idea, sorry.
- RcouF1uZ4gsC 11y agoTake a look at Intel thread building blocks. https://www.threadingbuildingblocks.org/tutorial-intel-tbb-task-based-programming https://www.threadingbuildingblocks.org/tutorial-intel-tbb-t... Also there is Microsoft REST SDK which includes task based programming. https://casablanca.codeplex.com/wikipage?title=Programming%20with%20Tasks&referringTitle=Documentation https://casablanca.codeplex.com/wikipage?title=Programming%2... Also there is async++ https://github.com/Amanieu/asyncplusplus/blob/master/README.md https://github.com/Amanieu/asyncplusplus/blob/master/README.... which is an implementation of the proposed c++ concurrency TS. In January 2016 the concurrency TS was accepted so we should start seeing implementations from the compiler vendors. https://gist.github.com/StephanTLavavej/996c41f7d3732c968ede https://gist.github.com/StephanTLavavej/996c41f7d3732c968ede
- steveklabnik 11y agoWe do want Rust to be excellent at parallel execution, but that does not mean that we don't pay attention to single-threaded performance either. The way that we make paralell/concurrent code better has no negative impact on single-threaded performance. In fact, sometimes you can use more efficient data structures when you know that you're not using multiple threads, like Arc<T> and Rc<T> for example.
- sitkack 11y agoExactly. Most C++ codebases lean too heavily on `shared_ptr` because they don't/can't know when something will cross a thread boundary.
- zanny 11y agoI think well designed C++ can maintain parity, especially with async() using http://en.cppreference.com/w/cpp/thread http://en.cppreference.com/w/cpp/thread. The problem is more that Rust is going to be automatic in your security more often, while C++ would require more thorough review. But the code in this article is micro-optimized, and overlooks the common trend of micro-optimization in C++ often leading you into the twilight zone of unexpected undocumented behavior and "luck" when getting desired results rather than granularity well defined syntax. You basically compare the two with artful precision which means you do not get to notice the very common trend of what is safe Rust is often unsafe C++ in the default design.
- pcwalton 11y ago> I think well designed C++ can maintain parity, especially with async() using http://en.cppreference.com/w/cpp/thread http://en.cppreference.com/w/cpp/thread. No, the entire point of Rust's "fearless concurrency" is guaranteed data race freedom by the compiler, something C++ doesn't even try to enforce. Modern C++ can still easily have data races.