Then again, often

  #pragma omp for

is a very low mental-overhead way to speed up code.

▲ MeetingsBrowser 14 hours ago | parent | next [-]

Depends on the code.

OpenMP does nothing to prevent data races, and anything beyond simple for loops quickly becomes difficult to reason about.

	▲	thesz 5 hours ago \| parent [-]
		No. It is easy to divide loop body into computation and share info update, the latter can be done under #pragma omp critical (label).

▲ nurettin 14 hours ago | parent | prev [-]

Yes! gcc/omp in general solved a lot of the problems which are conveniently left out in the article.

The we have the anecdotal "They failed firefox layout in C++ twice then did it in Rust" < to this I sigh in chrome.

▲

steveklabnik 14 hours ago | parent [-]

The Rust version of this is "turn .iter() into .par_iter()."

It's also true that for both, it's not always as easy as "just make the for loop parallel." Stylo is significantly more complex than that.

> to this I sigh in chrome.

I'm actually a Chrome user. Does Chrome do what Stylo does? I didn't think it did, but I also haven't really paid attention to the internals of any browsers in the last few years.

▲

pjmlp 14 hours ago | parent | next [-]

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

	▲	MeetingsBrowser 9 hours ago \| parent [-]
		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.

▲

nurettin 13 hours ago | parent | prev [-]

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

	▲	dwattttt 5 hours ago \| parent [-]
		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?