You don't need performance until you do. Writing slow rust in my experience is just as easy as writing python. If not easier because the libraries are better designed.
For example, safe rust forbids code which writes to different elements of the same vector from different CPU cores. C++ compiler has no objections, and doing that is often the best way to parallelize computations.
Different elements of the output vector may take very different time to compute. If you do parallelization with split_at_mut API, you won’t be able to saturate all cores because the thread who does the splitting can’t possibly know how much time each slice going to take.
Sometimes you don’t want libraries, instead you want to implement similar stuff in your own code. And Rayon uses unsafe to workround the compiler limitation of the safe rust I was talking about.
Sometimes you don’t want libraries, instead you want to implement similar stuff in your own code.
That's always the tradeoff, isn't it? You can implement the logic yourself, or modify three lines and immediately get parallel evaluation of you loop (add the dependency in Cargo.toml, add an import statement and modify an .iter() call to .par_iter()).
And Rayon uses unsafe to workround the compiler limitation of the safe rust I was talking about.
So does the standard library. Using unsafe is not a cheat, it's not a defeat. It is letting the library developer express something that the borrow checker cannot yet comprehend, at the cost of the developer taking responsibility of upholding the language's invariants.
Those "safe rust limitations" are the point, not an accident or misfeature. "If we restrict ourselves to handling the 90% most common cases of problems, we can automate the checks and provide an escape hatch for the other 10%" is the unofficial Rust ethos! The alternatives would be to either sacrifice performance in the general case or sacrifice safety in the general case.
Btw, the author of rayon is Niko Matsakis. It's not part of stdlib because of many reasons, but the quality of implementation is not one of them.
The poster has figured out a significant performance leak, their Y-axis is no longer nonsense, and they've got a peak indication so that we know the theoretical best possible numbers (no practical software will get there but indeed OpenMP is closer than Rayon)
I wouldn’t mind using unsafe rust for encapsulated cases where it makes sense (though this might not be the one as it could be done in safe rust).
It is just nice to have this delineation and it can simplify debugging as well.
I prefer different strategy. I use C++ for encapsulated cases where it makes sense. I compile that C++ into DLLs, and consume these DLLs from C#.
C++ is safer than unsafe Rust. C++ was designed for usability of the unsafe code because the entire ecosystem is unsafe, and have been that way for decades. By now, the tooling is pretty good.
And C# is safer than safe rust due to the VM. Rust compiles to native code. Unlike C# rust requires unsafe to implement any non-trivial data structures.
Not really, that’s just my impression reading stuff about unsafe rust, and programming C++.
wouldn’t your comparison need you to take into account unsafe constructs used to implement the C# VM?
Rust compiler depends on LLVM written in C++, kernels for all mainstream OSes are written in C.
The probability of bugs in my code I just written is orders of magnitude higher than probability of bugs in these third-party systems.
Rust compiler depends on LLVM written in C++, kernels for all mainstream OSes are written in C.
But this general criticism is just as valid for C# which you say is safer, isn't it? 18.6% of the C# runtime is written in C or C++[1] and you run the runtime on an OS that's largely written in C or C++.
"performance" is about profiling and avoiding bottlenecks.
That I'm using reference counting on the error path of my parser (so there's something wrong with the input and the task is not going to complete) is very unlikely to become a bottleneck.
You may have a point in that I navigated codebases that were plagued with shared ptrs everywhere in the past, and that general style of programming is not going to yield good performance. But you shouldn't deal in absolutes.
Comments
I am not going to be surprised to be downvoted, but you don't need shared_ptr in C++, that is itself overkill
The point of C++ is performance. If you don't need performance, why not just use Java or Python, why use Rust?
As a counterpoint, I also don't need to use `Rc` or `Arc` in Rust, and I can get by without reference counting. Why use C++?
You don't need performance until you do. Writing slow rust in my experience is just as easy as writing python. If not easier because the libraries are better designed.
The point of rust is you get the performance of C++ with additional safety.
For example, safe rust forbids code which writes to different elements of the same vector from different CPU cores. C++ compiler has no objections, and doing that is often the best way to parallelize computations.
It doesn't (see e.g. slice::split_at_mut). It however doesn't allow you to do that and mutate the vector at the same time.
Different elements of the output vector may take very different time to compute. If you do parallelization with split_at_mut API, you won’t be able to saturate all cores because the thread who does the splitting can’t possibly know how much time each slice going to take.
https://github.com/rayon-rs/rayon
Sometimes you don’t want libraries, instead you want to implement similar stuff in your own code. And Rayon uses unsafe to workround the compiler limitation of the safe rust I was talking about.
Also, it seems Rayon is substantially slower than C++ OpenMP https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comp...
That's always the tradeoff, isn't it? You can implement the logic yourself, or modify three lines and immediately get parallel evaluation of you loop (add the dependency in Cargo.toml, add an import statement and modify an .iter() call to .par_iter()).
So does the standard library. Using unsafe is not a cheat, it's not a defeat. It is letting the library developer express something that the borrow checker cannot yet comprehend, at the cost of the developer taking responsibility of upholding the language's invariants.
Those "safe rust limitations" are the point, not an accident or misfeature. "If we restrict ourselves to handling the 90% most common cases of problems, we can automate the checks and provide an escape hatch for the other 10%" is the unofficial Rust ethos! The alternatives would be to either sacrifice performance in the general case or sacrifice safety in the general case.
Btw, the author of rayon is Niko Matsakis. It's not part of stdlib because of many reasons, but the quality of implementation is not one of them.
This is probably a better link:
https://www.reddit.com/r/rust/comments/bto10h/update_a_scali...
The poster has figured out a significant performance leak, their Y-axis is no longer nonsense, and they've got a peak indication so that we know the theoretical best possible numbers (no practical software will get there but indeed OpenMP is closer than Rayon)
I wouldn’t mind using unsafe rust for encapsulated cases where it makes sense (though this might not be the one as it could be done in safe rust). It is just nice to have this delineation and it can simplify debugging as well.
I prefer different strategy. I use C++ for encapsulated cases where it makes sense. I compile that C++ into DLLs, and consume these DLLs from C#.
C++ is safer than unsafe Rust. C++ was designed for usability of the unsafe code because the entire ecosystem is unsafe, and have been that way for decades. By now, the tooling is pretty good.
And C# is safer than safe rust due to the VM. Rust compiles to native code. Unlike C# rust requires unsafe to implement any non-trivial data structures.
Do you have an example of C++ being safer than unsafe Rust?
As to C# being safer, wouldn’t your comparison need you to take into account unsafe constructs used to implement the C# VM?
Not really, that’s just my impression reading stuff about unsafe rust, and programming C++.
Rust compiler depends on LLVM written in C++, kernels for all mainstream OSes are written in C. The probability of bugs in my code I just written is orders of magnitude higher than probability of bugs in these third-party systems.
But this general criticism is just as valid for C# which you say is safer, isn't it? 18.6% of the C# runtime is written in C or C++[1] and you run the runtime on an OS that's largely written in C or C++.
[1] https://github.com/dotnet/runtime
The point of a program is first and foremost to be correct, performance is never more important than that. /dev/null is not in fact webscale.
You use Rust if you want performance (especially because there is no garbage collection), and strong safety guarantees.
If you don’t care about safety guarantees and abstractions like shared_ptr, you might just as well use C instead of C++.
"performance" is about profiling and avoiding bottlenecks.
That I'm using reference counting on the error path of my parser (so there's something wrong with the input and the task is not going to complete) is very unlikely to become a bottleneck.
You may have a point in that I navigated codebases that were plagued with shared ptrs everywhere in the past, and that general style of programming is not going to yield good performance. But you shouldn't deal in absolutes.