A Quick Benchmark Of Mozilla Firefox With WebRender Beta vs. Chrome

[Guest]

Of course, because of Rust.

WTF are you smoking? Rust is comparable in performance and in many cases faster than C++ and even C. Look at the benchmarks.

[Vash63]

is this for nightly? my about config only has
gfx.canvas.azure.backends skia
gfx.content.azure.backends skia

as options

Add them as booleans, a lot of the 'force-enable' type flags are not in the default config so you have to add them manually. I'm not sure if the 'content' one does anything as it didn't show up in about:support, but canvas definitely worked and layers.acceleration.force-enable is an absolute requirement to use Firefox IMO. Browser is a slow, ancient feeling mess without it.

[shmerl]

is this for nightly? my about config only has
gfx.canvas.azure.backends skia
gfx.content.azure.backends skia

as options

For any version. If you don't have such keys, create them.

[Weasel]

WTF are you smoking? Rust is comparable in performance and in many cases faster than C++ and even C. Look at the benchmarks.

Maybe badly written C/C++. WTF are you smoking thinking that adding EXTRA code (bounds checks) would EVER be faster, it's just logic.

[mmstick]

Maybe badly written C/C++. WTF are you smoking thinking that adding EXTRA code (bounds checks) would EVER be faster, it's just logic.

- Bounds checking on a modern CPU is effectively free of cost.
- Rust's compiler eliminates most bound checks anyway, so most of your time is spent elsewhere.
- Rust is already capable of generating more efficient machine code than C and C++, due to the extra type & lifetime information, and borrowck guarantees.

[Weasel]

- Bounds checking on a modern CPU is effectively free of cost.

Nothing redundant is ever free, it is a physical fact. Doing 2 things in parallel is not free either, since it wastes more energy. In this case, the branch predictor is not infinite.

- Rust's compiler eliminates most bound checks anyway, so most of your time is spent elsewhere.

Can't do that on input it doesn't know about (but the programmer does).

- Rust is already capable of generating more efficient machine code than C and C++, due to the extra type & lifetime information, and borrowck guarantees.

That's even less of an impact on a "modern CPU" than a branch which messes up with the branch predictor. You know, it has limited entries.

[mmstick]

Nothing redundant is ever free, it is a physical fact.

The cost of a bounds check is so small that it is effectively free. You seem to think that bounds checks consumes a lot of time and energy, when in fact it's more like 0.001% of your runtime.

Can't do that on input it doesn't know about (but the programmer does).

If the programmer knows the size of an input, then they are also able to prove it through the syntax. Arrays, even slices, can have a size specified and validated at compile-time. You won't have bounds checks if you can prove that it's not necessary. In many cases, bounds checks are eliminated entirely when using for loops and iterators in Rust, so you're barking up the wrong tree.

That's even less of an impact on a "modern CPU" than a branch which messes up with the branch predictor. You know, it has limited entries.

I have no idea what you're referring to. I was referring to compile-time information, which is used by the compiler to optimize the final output. These details aren't present at runtime...

[johnp117]

gfx.content.azure.accelerated true
gfx.canvas.azure.accelerated true

The first one doesn't exist (in the source code), the second one is deprecated.

shmerl Vash63

[shmerl]

It exposes us to a large amount of extra code and churn from Skia upstream. If we just relied on software Skia instead, we would avoid this problem and simplify Skia maintenance.

That sounds like a poor argument to prevent hardware acceleration as an option.

[johnp117]

It's not prevented (yet), only deprecated. And you conveniently left out the important part:

Software Skia performance is competitive and on some benchmarks (i.e. CanvasMark) our performance is actually better in software than with SkiaGL.