5 ms·

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 th

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.

glandium 3y ago
> safe rust forbids code which writes to different elements of the same vector from different CPU cores. 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.
- Const-me 3y ago
  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.
  - estebank 3y ago
    https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon
    - Const-me 3y ago
      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_comparison_of_rust_rayon_and_c_and/ https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comp...
      - tialaramex 3y ago
        This is probably a better link: https://www.reddit.com/r/rust/comments/bto10h/update_a_scaling_comparison_between_rustrayon_and/ 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)
      - estebank 3y ago
        > 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.
tomas789 3y ago
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.
- Const-me 3y ago
  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.
  - nequo 3y ago
    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?
    - Const-me 3y ago
      > an example of C++ being safer than unsafe Rust? 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.
      - nequo 3y ago
        > 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++. [1] https://github.com/dotnet/runtime https://github.com/dotnet/runtime

glandium 3y ago

> safe rust forbids code which writes to different elements of the same vector from different CPU cores. 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.

Const-me 3y ago
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.
- estebank 3y ago
  https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon
  - Const-me 3y ago
    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_comparison_of_rust_rayon_and_c_and/ https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comp...
    - tialaramex 3y ago
      This is probably a better link: https://www.reddit.com/r/rust/comments/bto10h/update_a_scaling_comparison_between_rustrayon_and/ 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)
    - estebank 3y ago
      > 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.

tomas789 3y ago

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.

Const-me 3y ago
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.
- nequo 3y ago
  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?
  - Const-me 3y ago
    > an example of C++ being safer than unsafe Rust? 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.
    - nequo 3y ago
      > 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++. [1] https://github.com/dotnet/runtime https://github.com/dotnet/runtime