The Rust version of this is "turn .iter() into .par_iter()." It's also true that...

pjmlp · 2026-01-14T15:59:52 1768406392

And the C++ version is add std::execution::par_unseq as parameter to the ranges algorithm.

MeetingsBrowser · 2026-01-14T20:44:33 1768423473

This has the same drawbacks as "#pragma omp for".

The hard part isn't splitting loop iterations between threads, but doing so _safely_.

Proving an arbitrary loop's iterations are split in a memory safe way is an NP hard problem in C and C++, but the default behavior in Rust.

pjmlp · 2026-01-15T06:43:56 1768459436

Well, if you are accessing global data with ranges, you are doing it wrong.

Naturally nothing on C++ prevents someone to do that, which is why PVS, Sonar and co exist.

Just like some things aren't prevented by Rust rather clippy.

jltsiren · 2026-01-15T08:33:58 1768466038

Concurrency is easy by default. The hard part is when you are trying to be clever.

You write concurrent code in Rust pretty much in the same way as you would write it in OpenMP, but with some extra syntax. Rust catches some mistakes automatically, but it also forces you to do some extra work. For example, you often have to wrap shared data in Arc when you convert single-threaded code to use multiple threads. And some common patterns are not easily available due to the limited ownership model. For example, you can't get mutable references to items in a shared container by thread id or loop iteration.

dwattttt · 2026-01-15T10:42:59 1768473779

> For example, you can't get mutable references to items in a shared container by thread id or loop iteration.

This would be a good candidate for a specialised container that internally used unsafe. Well, thread id at least; since the user of an API doesn't provide it, you could mark the API safe, since you wouldn't have to worry about incorrect inputs.

Loop iteration would be an input to the API, so you'd mark the API unsafe.

unrealhoang · 2026-01-15T12:45:36 1768481136

There’s split_at_mut to avoid writing unsafe yourself in this case.

nurettin · 2026-01-14T16:17:56 1768407476

Afaik it does all styling and layout in the main thread and offloads drawing instructions to other threads (CompositorTileWorker) and it works fine?

dwattttt · 2026-01-15T00:43:04 1768437784

That does sound like Chrome has also either failed to make styling multithreaded in C++ (or haven't attempted it), while it was achieved in Rust?