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

[johnp117]

Besides, Skia also now has Vulkan backend: https://skia.org/user/special/vulkan

That page isn't very reassuring:

At this time we find that many Vulkan drivers have bugs that Skia triggers for which we have no workaround. We are reporting bugs to vendors as we find them.

[shmerl]

Though the effort of improving Skia usage might be obsolete in the light of this: https://github.com/szeged/webrender/issues/198

[shmerl]

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

Opened a bug about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1502740

[shmerl]

I'm not convinced it's always better.

Besides, Skia also now has Vulkan backend: https://skia.org/user/special/vulkan

Did they try using it?

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

[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]

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

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

[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]

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.