4 ms·

Parallelism is hard in both Rust and C++. When I think about low level parallelism, like in the case of rendering, I believe that Safe Rust will only get you so

Parallelism is hard in both Rust and C++. When I think about low level parallelism, like in the case of rendering, I believe that Safe Rust will only get you so far perfomance-wise. To get the best speed you will still need unsafe. I'm wondering how their engine fares compared to Chrome.

steveklabnik 6y ago
You do not need to write unsafe code yourself in order to parallelize Rust code.
mdup 6y ago
It's entirely a myth that unsafe is needed to get speed boosts in Rust. Usually, the standard library, as well as other crates, offer optimal performance without resorting to unsafe code. (If we go pedantic, Vec and other primitives do rely on unsafe, but the point is as an application developer you don't have to write unsafe code yourself.)
- twic 6y ago
  It's not entirely a myth. There are situations where you can't get the compiler to emit optimal code using only safe Rust. You can go a very long way with only safe Rust (and i do!), but not everywhere.
  - jononor 6y ago
    There are also situations where you cannot get a C++ compiler to emit optimal code without resorting to intrinsics or inline Assembly. 99% of Rust and C++ code performs well without going that deep.
- skohan 6y ago
  Unsafe rust exists for a reason. There are cases where perfectly safe code cannot be expressed according to Rust's ownership rules, and an escape hash is needed. Of course the "average" developer probably should not resort to unsafe as a rule of thumb. Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. For example, I understand that the standard library makes use of specialization, which remains an unstable feature because of a soundness hole in the implementation.
  - oconnor663 6y ago
    > Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. I think you're misunderstanding the parent comment. The stdlib constantly resorts to unsafe code. Tons of methods like `split_at_mut` and `make_ascii_uppercase` are just safe wrappers around an unsafe one-liner. Rather, the observation is that _with the benefit of the stdlib and common crates_, most programs have no performance reason to reach for unsafe in regular code. That's true in my experience.
    - skohan 6y ago
      I agree that most developers don't need to bother with unsafe code, and will not pay a performance penalty for staying within safe rust. My only point is that it's not necessary to be so dogmatic as to say that no-one should ever write a line of unsafe rust. For instance, if you read the rust book, they make references to times you might want to use unsafe: > Borrowing different parts of a slice is fundamentally okay because the two slices aren’t overlapping, but Rust isn’t smart enough to know this. When we know code is okay, but Rust doesn’t, it’s time to reach for unsafe code.
      - oconnor663 6y ago
        Agreed. My guess is that folks tend to talk past each other on these questions, and that the important details aren't really controversial.
  - simias 6y ago
    In my experience most of the time I had to use unsafe was to bind unsafe interface (think something like making raw OpenGL bindings for instance, you'll have unsafe code all over the place and you'll have write your own safe wrappers around it). Performance-wise I very rarely find myself having to compromise, although there are times where I have to write "smarter", more complicated code to get good performance without unsafe. I just looked at the code of a pretty heavily optimized program I've been working on for a few months, I have exactly one instance of unsafe in the code: pub const GPIO_ID: StreamId = StreamId(unsafe { NonZeroU16::new_unchecked(0xf610) }); I need the unsafe because at the moment the language is not smart enough to understand that 0xf610 is obviously non-zero and that I can build a NonZeroU16 from it without fail (at least I don't know how to express this in static expression at the moment). This has no performance implications whatsoever.
bzbarsky 6y ago
For that last one: it's much faster in many cases, because Chrome's engine is not parallelized. Back when I was last measuring this, stylo's single-thread performance was comparable to Chrome's or a bit faster in some cases. Parallelized performance was much better. That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores.
- oblio 6y ago
  > That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores. True, but that's probably about to change soon. Look at the ARM stuff about to enter the arena. I wouldn't bet on us using just 2-4 cores 10 years from now. And we need to plan for that.
  - bzbarsky 6y ago
    Well, right, that's why the Firefox CSS implementation actually aims to be parallelized and has been for years. I'm just saying that the wins from that on current hardware are not as large as one would hope. And that the increase in number of cores has not been increasing nearly as fast as one would like, in devices that most people actually own.
    - oblio 6y ago
      Yeah, it's a chicken and egg problem. Old software doesn't use many cores, and even new, single threaded one doesn't (Javascript, Python, Ruby, etc.). Because software doesn't really need many cores, no need to create CPUs with many, many cores. I imagine the cycle's going to break at some point, after all we can only ignore having many cores for so long. Especially that now even mobile devices routinely have at least 4 cores.
simias 6y ago
It's not really scientific but if you look at the language benchmark game Rust is generally toe-to-toe with C++ without requiring any unsafe code. Here's a random example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Rust is pretty damn close to the fastest C++ version without any unsafe (but using a bunch of generic libraries which may have unsafe code, to be perfectly fair). Note that the winning C++ entry is also vastly more complex code and I wouldn't want to have to maintain that. The n-body benchmark is even more in Rust's favour: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-8.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Here Rust wins the benchmark without unsafe or non-std dependencies. I also find the code very readable and natural looking. Disclaimer: I love Rust so much that I wish that I could marry it, I'm obviously thoroughly biased.
- pumpkinpal 6y ago
  The n-body benchmark is slower due to a a bug in GCC's vectorization compared to Clang/LLVM.

steveklabnik 6y ago

You do not need to write unsafe code yourself in order to parallelize Rust code.

mdup 6y ago

It's entirely a myth that unsafe is needed to get speed boosts in Rust. Usually, the standard library, as well as other crates, offer optimal performance without resorting to unsafe code. (If we go pedantic, Vec and other primitives do rely on unsafe, but the point is as an application developer you don't have to write unsafe code yourself.)

twic 6y ago
It's not entirely a myth. There are situations where you can't get the compiler to emit optimal code using only safe Rust. You can go a very long way with only safe Rust (and i do!), but not everywhere.
- jononor 6y ago
  There are also situations where you cannot get a C++ compiler to emit optimal code without resorting to intrinsics or inline Assembly. 99% of Rust and C++ code performs well without going that deep.
skohan 6y ago
Unsafe rust exists for a reason. There are cases where perfectly safe code cannot be expressed according to Rust's ownership rules, and an escape hash is needed. Of course the "average" developer probably should not resort to unsafe as a rule of thumb. Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. For example, I understand that the standard library makes use of specialization, which remains an unstable feature because of a soundness hole in the implementation.
- oconnor663 6y ago
  > Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. I think you're misunderstanding the parent comment. The stdlib constantly resorts to unsafe code. Tons of methods like `split_at_mut` and `make_ascii_uppercase` are just safe wrappers around an unsafe one-liner. Rather, the observation is that _with the benefit of the stdlib and common crates_, most programs have no performance reason to reach for unsafe in regular code. That's true in my experience.
  - skohan 6y ago
    I agree that most developers don't need to bother with unsafe code, and will not pay a performance penalty for staying within safe rust. My only point is that it's not necessary to be so dogmatic as to say that no-one should ever write a line of unsafe rust. For instance, if you read the rust book, they make references to times you might want to use unsafe: > Borrowing different parts of a slice is fundamentally okay because the two slices aren’t overlapping, but Rust isn’t smart enough to know this. When we know code is okay, but Rust doesn’t, it’s time to reach for unsafe code.
    - oconnor663 6y ago
      Agreed. My guess is that folks tend to talk past each other on these questions, and that the important details aren't really controversial.
- simias 6y ago
  In my experience most of the time I had to use unsafe was to bind unsafe interface (think something like making raw OpenGL bindings for instance, you'll have unsafe code all over the place and you'll have write your own safe wrappers around it). Performance-wise I very rarely find myself having to compromise, although there are times where I have to write "smarter", more complicated code to get good performance without unsafe. I just looked at the code of a pretty heavily optimized program I've been working on for a few months, I have exactly one instance of unsafe in the code: pub const GPIO_ID: StreamId = StreamId(unsafe { NonZeroU16::new_unchecked(0xf610) }); I need the unsafe because at the moment the language is not smart enough to understand that 0xf610 is obviously non-zero and that I can build a NonZeroU16 from it without fail (at least I don't know how to express this in static expression at the moment). This has no performance implications whatsoever.

bzbarsky 6y ago

For that last one: it's much faster in many cases, because Chrome's engine is not parallelized. Back when I was last measuring this, stylo's single-thread performance was comparable to Chrome's or a bit faster in some cases. Parallelized performance was much better. That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores.

oblio 6y ago
> That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores. True, but that's probably about to change soon. Look at the ARM stuff about to enter the arena. I wouldn't bet on us using just 2-4 cores 10 years from now. And we need to plan for that.
- bzbarsky 6y ago
  Well, right, that's why the Firefox CSS implementation actually aims to be parallelized and has been for years. I'm just saying that the wins from that on current hardware are not as large as one would hope. And that the increase in number of cores has not been increasing nearly as fast as one would like, in devices that most people actually own.
  - oblio 6y ago
    Yeah, it's a chicken and egg problem. Old software doesn't use many cores, and even new, single threaded one doesn't (Javascript, Python, Ruby, etc.). Because software doesn't really need many cores, no need to create CPUs with many, many cores. I imagine the cycle's going to break at some point, after all we can only ignore having many cores for so long. Especially that now even mobile devices routinely have at least 4 cores.

simias 6y ago

It's not really scientific but if you look at the language benchmark game Rust is generally toe-to-toe with C++ without requiring any unsafe code. Here's a random example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Rust is pretty damn close to the fastest C++ version without any unsafe (but using a bunch of generic libraries which may have unsafe code, to be perfectly fair). Note that the winning C++ entry is also vastly more complex code and I wouldn't want to have to maintain that. The n-body benchmark is even more in Rust's favour: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-8.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Here Rust wins the benchmark without unsafe or non-std dependencies. I also find the code very readable and natural looking. Disclaimer: I love Rust so much that I wish that I could marry it, I'm obviously thoroughly biased.

pumpkinpal 6y ago
The n-body benchmark is slower due to a a bug in GCC's vectorization compared to Clang/LLVM.