Hacker News Reader

Comment by johnnycerberus | Hacker News Reader

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.

View on HN

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.)

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.

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.

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.

> 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.

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.

Agreed. My guess is that folks tend to talk past each other on these questions, and that the important details aren't really controversial.

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.

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 shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores.

> That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. 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.

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.

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.

Mobile devices in the field typically have _more_ cores that desktop devices. The Firefox hardware report is strongly influenced by there being a lot more desktop than mobile Firefox users.

As you note, the modal number of cores on mobile has been 4-6 for a while now.

I remember reading that Chromium's engine is slower sometimes because it follows the standard more strictly. https://codeberg.org/teddit/teddit/issues/24#issuecomment-16...

Fwiw, I've seen a number of cases of the other way around: the WebKit/Chrome CSS implementation had some shortcuts for performance reasons that caused them to not follow the spec, where Firefox did.

The link you posted just indicates that Firefox rendered the page faster than Chrome; did it render it _wrong_?

One other note: the linked issue here is layout, not the CSS system per se; this part is not parallelized in Gecko and is still in C++, not in Rust.

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/...

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/...

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.

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

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

Reply on news.ycombinator.com