5 ms·

So you are telling me that a parallel CSS engine can't be usable if written in C++ but large scale particle/molecule simulators, AAA game engines and other high

So you are telling me that a parallel CSS engine can't be usable if written in C++ but large scale particle/molecule simulators, AAA game engines and other high-fidelity simulator environments are 100% C++ codebases?

dmos62 6y ago
The quote says that a parallel CSS engine in C++ was hard to get right in their case.
- skohan 6y ago
  The post's claim is: > C++ simply wasn't usable for writing a parallel CSS engine. That's a stronger claim than that C++ was hard to get right. It's a claim that the language is not up to the task.
  - bzbarsky 6y ago
    When the time cost of getting it right and _keeping_ it right exceeds the amount of time actually available in a day, the result is equivalent to "the language is not up to the task". I mean, you can implement anything you want in assembly, in theory. In practice, the cost of iteration tends to be high enough that implementing things with somewhat rapidly changing requirements (which includes CSS, to be clear!) pretty much requires a language in which iteration and refactoring can be done more quickly than in assembly. Maybe the confusion on your part is that you think "CSS" is a static set of requirements, so if you put in enough effort to implement it once you're then done? Unfortunately, that's not how it works in practice.
    - skohan 6y ago
      The fact that we disagree does not imply "confusion on my part". > When the time cost of getting it right and _keeping_ it right exceeds the amount of time actually available in a day, the result is equivalent to "the language is not up to the task". Again, this is referring to the particular approach that the Mozilla team took to the problem. If anything, one of the most valid criticisms of C++ is that the API is too large, and it has too many tools to work with at the expense of clarity. C++ allows you to express just about anything, and I do not think the standard of evidence has been met that the problem of writing a CSS engine could not be expressed in C++ in a way which would be both performant and maintainable. C++ has been used for many complex, high-profile projects which are widely used. There is nothing magical about CSS which creates problems C++ is incapable of solving.
      - bzbarsky 6y ago
        In the limit, you could implement a DSL in C++ that would allow you to implement CSS. Or you could implement Rust in C++. As you say, you can do whatever you want in C++. The only question is how much time and effort it would take and whether it's worth it. I will note that the people who worked on the Firefox style system had plenty of experience working on complex, high-profile C++ projects. Every single one of them that I've talked to agreed that for the specific thing they were doing here Rust allowed much faster development of code with fewer bugs (especially as measured by how many issues the fuzzers found) than their past experience with C++ had been. If your point is that the claim should be "parallelizing the style system in C++ was impossible within the schedule and manpower constraints Firefox was operating under" rather than the simpler "was impossible" claim, then sure, as a purely logical-statement matter. But in practice there are always schedule and manpower constraints. Can I prove mathematically that some other team would not have been able to achieve the same results in the same amount of time with C++? No, I can't; such a proof would be quite difficult to construct. I do have the empirical observation that there used to be at least four fairly different modern non-parallel CSS implementations out there written in C++ (Gecko, WebKit, Blink, Edge), and that one of them has disappeared (Edge), one was parallelized in Rust, and the remaining two remain in C++ and non-parallel, even though people generally agree that parallelizing them would be good and so forth. Maybe it's just that none of the organizations involved are any good at writing C++ code. Maybe it's that doing this in C++ is hard enough that it's not worth the effort. Maybe it's something else. What is your hypothesis on the matter?
        skohan 6y ago
        > parallelizing the style system in C++ was impossible within the schedule and manpower constraints Firefox was operating under So my main issue with this claim is that we are talking about proving the negative. Not to get too pedantic, but the reasoning seems to be: 1. Mozilla tried and failed to build a parallel CSS engine in C++ 2. Mozilla succeeded in building a parallel CSS engine in Rust 3. Therefore, it is impossible to implement a parallel CSS engine in C++ (under the constraints Mozilla was under). This is simply not a valid argument. Evidence that something did not happen is not proof that it could not happen. There are plenty of claims I would accept: - The Mozilla team found Rust much better than C++ for solving their problem - Many of the problems the team was running into with C++ were completely eliminated by the constraints provided by Rust But saying this problem is impossible to solve in C++ is an extraordinary claim which needs extraordinary evidence. C++ is an extremely flexible and powerful language, to say that no one could ever design a solution to this problem using C++ requires a very limited imagination. > there used to be at least four fairly different modern non-parallel CSS implementations out there written in C++ (Gecko, WebKit, Blink, Edge), and that one of them has disappeared (Edge), one was parallelized in Rust, and the remaining two remain in C++ and non-parallel, even though people generally agree that parallelizing them would be good and so forth. This is a very small sample size. If I have to give a hypothesis, I can imagine that having a very large, very mature code base like Firefox would have placed a lot of design constraints on any rewrite of the CSS engine. I can imagine that working within this framework, there may have been many problems related to concurrency and data ownership which ended up eating a lot of time and energy in C++, and the team saw a huge productivity boost categorically eliminating these problems. But I simply do not believe it's the case that it's not possible to decompose the problems a CSS engine has to solve into a set of concurrent data structures and operations, which could be expressible in either Rust or C++.
  - oblio 6y ago
    If the tool exceeds human ability in practice, then yes. I mean, we can blame the humans all we want, but that won't take us anywhere. Look at what happened to airplane safety and car safety when we stopped blaming the pilot/driver. Fatalities plummeted.
- johnnycerberus 6y ago
  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.
emn13 6y ago
Typically simulators don't benefit much from extremely fine-grained parallelism; while you likely can simulate each entities behavior in parallel, and then step the world, you don't have fine-grained dependencies within one step (and likely many entities computations have predictable and balanced computational costs, further simplifying parallelism). AAA games were certainly until recently renowned for their poor usage of parallelism, though perhaps there are exceptions - but remember, large scale data-parallelism akin to simulations isn't the problem; it's problematic once there are dependency cycles and/or parallelism needs to be particularly fine-grained. Finally, many games and simulators are written in clearly, clearly sub-"optimal" fashion. Games are about fun; not necessarily about extracting maximal possible performance - and compared to browsers, even to minor players like Firefox, even large games have limited usage and especially limited lifetime usage, and they're likely less sensitive to security issues too. As a result, when a game's usage of of parallelism has a few very unlikely race conditions that might not be a show-stopper - whereas it could be an exploitable flaw in browsers. All in all, it's extremely plausible that games+sims aren't quite as dramatically impacted by C++'s risks as a browser's styling engine is. It's perhaps no coincidence that the language was pretty much designed for it.
vvanders 6y ago
Having worked in a AAA engine, with some of the things I saw done to make the performance tradeoffs I wouldn't want that code style anywhere near a security sensitive domain like the browser.
- saagarjha 6y ago
  Wait until you see the things that are done in browsers to make them fast.
xfer 6y ago
Nobody cares if any of those are exploitable, but browsers are literally the os for a lot of people and needs to be secure.
lmm 6y ago
In my experience all of those simulators and game engines have really egregious bugs that go undetected. C++ is fine if you don't need correctness (which is actually most of the time, in practice).
cpeterso 6y ago
AAA game engines don’t need to securely execute arbitrary malicious code downloaded from the internet.
coldtea 6y ago
AAA games usually have the shoddiest code.

dmos62 6y ago

The quote says that a parallel CSS engine in C++ was hard to get right in their case.

skohan 6y ago
The post's claim is: > C++ simply wasn't usable for writing a parallel CSS engine. That's a stronger claim than that C++ was hard to get right. It's a claim that the language is not up to the task.
- bzbarsky 6y ago
  When the time cost of getting it right and _keeping_ it right exceeds the amount of time actually available in a day, the result is equivalent to "the language is not up to the task". I mean, you can implement anything you want in assembly, in theory. In practice, the cost of iteration tends to be high enough that implementing things with somewhat rapidly changing requirements (which includes CSS, to be clear!) pretty much requires a language in which iteration and refactoring can be done more quickly than in assembly. Maybe the confusion on your part is that you think "CSS" is a static set of requirements, so if you put in enough effort to implement it once you're then done? Unfortunately, that's not how it works in practice.
  - skohan 6y ago
    The fact that we disagree does not imply "confusion on my part". > When the time cost of getting it right and _keeping_ it right exceeds the amount of time actually available in a day, the result is equivalent to "the language is not up to the task". Again, this is referring to the particular approach that the Mozilla team took to the problem. If anything, one of the most valid criticisms of C++ is that the API is too large, and it has too many tools to work with at the expense of clarity. C++ allows you to express just about anything, and I do not think the standard of evidence has been met that the problem of writing a CSS engine could not be expressed in C++ in a way which would be both performant and maintainable. C++ has been used for many complex, high-profile projects which are widely used. There is nothing magical about CSS which creates problems C++ is incapable of solving.
    - bzbarsky 6y ago
      In the limit, you could implement a DSL in C++ that would allow you to implement CSS. Or you could implement Rust in C++. As you say, you can do whatever you want in C++. The only question is how much time and effort it would take and whether it's worth it. I will note that the people who worked on the Firefox style system had plenty of experience working on complex, high-profile C++ projects. Every single one of them that I've talked to agreed that for the specific thing they were doing here Rust allowed much faster development of code with fewer bugs (especially as measured by how many issues the fuzzers found) than their past experience with C++ had been. If your point is that the claim should be "parallelizing the style system in C++ was impossible within the schedule and manpower constraints Firefox was operating under" rather than the simpler "was impossible" claim, then sure, as a purely logical-statement matter. But in practice there are always schedule and manpower constraints. Can I prove mathematically that some other team would not have been able to achieve the same results in the same amount of time with C++? No, I can't; such a proof would be quite difficult to construct. I do have the empirical observation that there used to be at least four fairly different modern non-parallel CSS implementations out there written in C++ (Gecko, WebKit, Blink, Edge), and that one of them has disappeared (Edge), one was parallelized in Rust, and the remaining two remain in C++ and non-parallel, even though people generally agree that parallelizing them would be good and so forth. Maybe it's just that none of the organizations involved are any good at writing C++ code. Maybe it's that doing this in C++ is hard enough that it's not worth the effort. Maybe it's something else. What is your hypothesis on the matter?
      - skohan 6y ago
        > parallelizing the style system in C++ was impossible within the schedule and manpower constraints Firefox was operating under So my main issue with this claim is that we are talking about proving the negative. Not to get too pedantic, but the reasoning seems to be: 1. Mozilla tried and failed to build a parallel CSS engine in C++ 2. Mozilla succeeded in building a parallel CSS engine in Rust 3. Therefore, it is impossible to implement a parallel CSS engine in C++ (under the constraints Mozilla was under). This is simply not a valid argument. Evidence that something did not happen is not proof that it could not happen. There are plenty of claims I would accept: - The Mozilla team found Rust much better than C++ for solving their problem - Many of the problems the team was running into with C++ were completely eliminated by the constraints provided by Rust But saying this problem is impossible to solve in C++ is an extraordinary claim which needs extraordinary evidence. C++ is an extremely flexible and powerful language, to say that no one could ever design a solution to this problem using C++ requires a very limited imagination. > there used to be at least four fairly different modern non-parallel CSS implementations out there written in C++ (Gecko, WebKit, Blink, Edge), and that one of them has disappeared (Edge), one was parallelized in Rust, and the remaining two remain in C++ and non-parallel, even though people generally agree that parallelizing them would be good and so forth. This is a very small sample size. If I have to give a hypothesis, I can imagine that having a very large, very mature code base like Firefox would have placed a lot of design constraints on any rewrite of the CSS engine. I can imagine that working within this framework, there may have been many problems related to concurrency and data ownership which ended up eating a lot of time and energy in C++, and the team saw a huge productivity boost categorically eliminating these problems. But I simply do not believe it's the case that it's not possible to decompose the problems a CSS engine has to solve into a set of concurrent data structures and operations, which could be expressible in either Rust or C++.
- oblio 6y ago
  If the tool exceeds human ability in practice, then yes. I mean, we can blame the humans all we want, but that won't take us anywhere. Look at what happened to airplane safety and car safety when we stopped blaming the pilot/driver. Fatalities plummeted.
johnnycerberus 6y ago
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.

emn13 6y ago

Typically simulators don't benefit much from extremely fine-grained parallelism; while you likely can simulate each entities behavior in parallel, and then step the world, you don't have fine-grained dependencies within one step (and likely many entities computations have predictable and balanced computational costs, further simplifying parallelism). AAA games were certainly until recently renowned for their poor usage of parallelism, though perhaps there are exceptions - but remember, large scale data-parallelism akin to simulations isn't the problem; it's problematic once there are dependency cycles and/or parallelism needs to be particularly fine-grained. Finally, many games and simulators are written in clearly, clearly sub-"optimal" fashion. Games are about fun; not necessarily about extracting maximal possible performance - and compared to browsers, even to minor players like Firefox, even large games have limited usage and especially limited lifetime usage, and they're likely less sensitive to security issues too. As a result, when a game's usage of of parallelism has a few very unlikely race conditions that might not be a show-stopper - whereas it could be an exploitable flaw in browsers. All in all, it's extremely plausible that games+sims aren't quite as dramatically impacted by C++'s risks as a browser's styling engine is. It's perhaps no coincidence that the language was pretty much designed for it.

vvanders 6y ago

Having worked in a AAA engine, with some of the things I saw done to make the performance tradeoffs I wouldn't want that code style anywhere near a security sensitive domain like the browser.

saagarjha 6y ago
Wait until you see the things that are done in browsers to make them fast.

xfer 6y ago

Nobody cares if any of those are exploitable, but browsers are literally the os for a lot of people and needs to be secure.

lmm 6y ago

In my experience all of those simulators and game engines have really egregious bugs that go undetected. C++ is fine if you don't need correctness (which is actually most of the time, in practice).

cpeterso 6y ago

AAA game engines don’t need to securely execute arbitrary malicious code downloaded from the internet.

coldtea 6y ago

AAA games usually have the shoddiest code.