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

[Michael_S]

I don't understand why anyone touts browser benchmark results to end users. A browser is a UX first product where input latency and scrolling smoothness are of paramount importance. Chrome scroll lags on all existing hardware, while other browsers are smooth. Everything else is irrelevant.

When the user touches a Java application, it lags and stutters. That's an automatic fail. Everything else is irrelevant. Users don't care about garbage collection and other implementation details.

While I agree completely with your point that real world GUI performance matters more than arbitrary benchmarks, my experience with Chrome on Linux doesn't match yours at all. Chrome is consistently smoother and more responsive for me on Linux. I use Firefox anyway because I trust the Mozilla Foundation (marginally) more than I trust Alphabet.

And I'm guessing you haven't run Java in a GUI application in more than ten years. Java GUI apps sucked in the early days because the language implementation was terrible and hardware was inadequate. Minecraft doesn't drop below 50 fps on my computers, and they're all five years old or older.

[Monstieur]

While I agree completely with your point that real world GUI performance matters more than arbitrary benchmarks, my experience with Chrome on Linux doesn't match yours at all. Chrome is consistently smoother and more responsive for me on Linux. I use Firefox anyway because I trust the Mozilla Foundation (marginally) more than I trust Alphabet.

And I'm guessing you haven't run Java in a GUI application in more than ten years. Java GUI apps sucked in the early days because the language implementation was terrible and hardware was inadequate. Minecraft doesn't drop below 50 fps on my computers, and they're all five years old or older.

I forgot this was on Linux. I was talking about Windows, where Firefox and Edge visibly trounce Chrome & Opera in scrolling smoothness, input latency, UI perfomance (UI animations seem to be capped at 60 fps in both Chrome & Opera). This is especially visible on 144+ Hz monitors. The same holds true for Firefox and Safari on macOS as well compared to Chrome & Opera.

Java / Android games go out of their way to avoid triggering garbage collection and inducing stutters. However regular application developers don't do this and the runtime triggers GC as usual, resulting in freezes when performing continuous UI operations. I use Eclipse, Android Studio and some other Java tools on both macOS and Windows, and the UI performance is terrible compared to Xcode and native editors on Windows (the WPF based Vistual Studio 2008+ are not among them). I mean they are utterly crushed by native applications that run at 240 fps on my 240 Hz monitor. The Java applications slow down to 10 fps under load.

[Monstieur]

Regarding WebRender, I got the same MotionMark score of ~330 on my MacBook (2.6 GHz i7-6700HQ, Radeon RX560) and my desktop (4.5 GHz i7-4820K, RTX 2080 Ti) after force enabling it on both.

[Weasel]

They let anyone who wants to submit an entry in any language with or without frameworks in a pull request. So they didn't pick anything. That's why in the same selection you picked there is a C++ entry that has 1.1% the speed of the C++ leader. And these periodic contests have been going on for years, so it's not like the C++ community hasn't had time to do better.

Now justify why the fortunes benchmark where C++ wins is the 'realistic' option and all of the ones where Java or Rust leads are not.

Because C++ has zero overhead when used properly? And I mean that literally. Not "branch prediction is free on modern CPUs", that's not zero overhead, it adds instructions to the code, so it is some overhead. C++ can literally add zero measurable overhead. So it is literally impossible for Rust to be faster.

Rust does add shitty checks behind your back tho, unless you use unsafe blocks. So, that's a measurable overhead. By measurable, I mean even 1 single extra byte of instruction.

Obviously, one can write C++ with a million shitty standard library abstractions or Boost or w/e and then QQ that C++ is slower when in fact it's just his shitty use of C++ that's slower and handicapped.

[Michael_S]

Because C++ has zero overhead when used properly? And I mean that literally. Not "branch prediction is free on modern CPUs", that's not zero overhead, it adds instructions to the code, so it is some overhead. C++ can literally add zero measurable overhead. So it is literally impossible for Rust to be faster.

You don't understand Rust. Most of what Rust does is compiler-done compile time ownership checking of references. So the exact same things C++ is doing for you with unique_ptr and shared_ptr, except instead of the developer needing to remember to use unique_ptr and shared_ptr the compiler is automatically doing it for you. The exact same zero level runtime overhead results.

That's what Rust provides. Not automatic runtime bounds checking. And that's why Rust literally matches C++ for performance and that's why the people at Mozilla that designed Rust were trying to make a memory-safe C++ replacement with no performance trade off.

See also ATS, which does the same kind of thing. It's a compiler-only layer on top of raw C, with nothing added to runtime. It just provides compile time guarantees against memory leaks and buffer overruns and use-after-free errors.

Rust does add shitty checks behind your back tho, unless you use unsafe blocks. So, that's a measurable overhead. By measurable, I mean even 1 single extra byte of instruction.

Obviously, one can write C++ with a million shitty standard library abstractions or Boost or w/e and then QQ that C++ is slower when in fact it's just his shitty use of C++ that's slower and handicapped.

Then submit code to those benchmarks to take the speed crown back from Rust in the three benchmarks where the best Rust submission beats the best C++ submission. You don't have to start from nothing, you can modify one of the existing solutions.

[Michael_S]

I forgot this was on Linux. I was talking about Windows, where Firefox and Edge visibly trounce Chrome & Opera in scrolling smoothness, input latency, UI perfomance (UI animations seem to be capped at 60 fps in both Chrome & Opera). This is especially visible on 144+ Hz monitors. The same holds true for Firefox and Safari on macOS as well compared to Chrome & Opera.

I will take your word on it. No sarcasm. I use Linux everywhere except a mediocre Windows laptop for work, and on that one I never open Chrome so I don't have a comparison.

Java / Android games go out of their way to avoid triggering garbage collection and inducing stutters. However regular application developers don't do this and the runtime triggers GC as usual, resulting in freezes when performing continuous UI operations. I use Eclipse, Android Studio and some other Java tools on both macOS and Windows, and the UI performance is terrible compared to Xcode and native editors on Windows (the WPF based Vistual Studio 2008+ are not among them). I mean they are utterly crushed by native applications that run at 240 fps on my 240 Hz monitor. The Java applications slow down to 10 fps under load.

I don't think IDEs are a great example of what programming languages to use for desktop applications just because they're so inherently complicated. But aside from Minecraft and the Minecraft clone Terasology (which also gets very high fps for me) I don't use any other Java desktop applications besides Eclipse. So I don't really have grounds to compare. I also don't have any displays faster than 60 Hz, so to be fair to you I am not in a position to notice a difference.

[Monstieur]

I get the same MotionMark score with WebRender on and off, however the framerate is visibly higher with WebRender on.

[Weasel]

You don't understand Rust. Most of what Rust does is compiler-done compile time ownership checking of references. So the exact same things C++ is doing for you with unique_ptr and shared_ptr, except instead of the developer needing to remember to use unique_ptr and shared_ptr the compiler is automatically doing it for you. The exact same zero level runtime overhead results.

That's what Rust provides. Not automatic runtime bounds checking. And that's why Rust literally matches C++ for performance and that's why the people at Mozilla that designed Rust were trying to make a memory-safe C++ replacement with no performance trade off.

See also ATS, which does the same kind of thing. It's a compiler-only layer on top of raw C, with nothing added to runtime. It just provides compile time guarantees against memory leaks and buffer overruns and use-after-free errors.

I think it's funny that you clearly imply you know more about Rust (I admit I'm not interested in it much) and you don't know it does automatic bounds checking at runtime without unsafe blocks? Seriously dude?

First hit on Google: https://til.hashrocket.com/posts/9f3...ked-at-runtime

At least learn the stuff you preach so much properly.

[Michael_S]

I think it's funny that you clearly imply you know more about Rust (I admit I'm not interested in it much) and you don't know it does automatic bounds checking at runtime without unsafe blocks? Seriously dude?

First hit on Google: https://til.hashrocket.com/posts/9f3...ked-at-runtime

At least learn the stuff you preach so much properly.

And if you keep reading about Rust, you'll see that the preferred/recommended way to do array iteration in Rust is using a for construct, https://doc.rust-lang.org/std/primitive.array.html
let mut array: [i32; 3] = [0; 3]; for x in &array { print!("{} ", x); } and in that particular case, the bounds check is eliminated. ...which, you know, might explain why Rust is matching or beating C++ in a mess of benchmarks.

Edit: I apologize, I have been unkind. But I don't understand your belief that Rust is inherently slow. The people that built the language set as their goal matching C++ runtime performance and memory efficiency while guarding against certain classes of errors. Yes, if you use a C-family style for (int i = 0; i < ... ; i++) {} loop then Rust by default puts in a bounds check and it will slow you down. Their solution was to recommend iterator-style iteration. All available evidence is that they have succeeded on their performance goals.

[Weasel]

And if you keep reading about Rust, you'll see that the preferred/recommended way to do array iteration in Rust is using a for construct, https://doc.rust-lang.org/std/primitive.array.html
let mut array: [i32; 3] = [0; 3]; for x in &array { print!("{} ", x); } and in that particular case, the bounds check is eliminated. ...which, you know, might explain why Rust is matching or beating C++ in a mess of benchmarks.

Yeah, but I wasn't talking about iterating through an array only. And since Rust doesn't have pointers without unsafe blocks...

Edit: I apologize, I have been unkind. But I don't understand your belief that Rust is inherently slow. The people that built the language set as their goal matching C++ runtime performance and memory efficiency while guarding against certain classes of errors. Yes, if you use a C-family style for (int i = 0; i < ... ; i++) {} loop then Rust by default puts in a bounds check and it will slow you down. Their solution was to recommend iterator-style iteration. All available evidence is that they have succeeded on their performance goals.

The point is: any language that adds checks behind your back is stupid. I'm sure Mozilla made Rust to match C++, but the problem is that it was their "idiomatic" C++ which is FULL of bounds checking so they assume all C++ code is, but that's simply not true.

C++ (the language, not libraries) does not add checks behind your back for basic stuff -- yeah, you do get those for standard library containers but those are not part of the language proper: they're just classes that you can also implement yourself and avoid the runtime checks if you want to, without "damaging" the code clarity, since it will look the same. Not so much for Rust (except using unsafe blocks) since they are baked into the language itself.

This is why I have a dislike for any language (not container) that does runtime checks on bounds, or has integrated garbage collector in the LANGUAGE instead of having it as a library, and so on.