Benchmarking Mercury As The "Fastest Firefox Fork" With AVX, AES, LTO + PGO

[Anux]

It might be anecdotal evidence, but I remember once started using the Fedora Firefox package and immediately noticed that YouTube and some other websites were loading slower than usual.

That has nothing to do with evidence you just had some strange problem, maybe dns resolve? Because if youtube loaded in 2000 ms on one system and 2200 ms on another (just leaving out that load times are nearly unaffected by browser performance) you couldn't even notice it if you had both systems running in parallel and tried to press the buttons at the same time. And you are talking about one after another with probably > 10 min in between tests. More likely one load needed 2 s and the other 4 s, that would be easy to notice but that is already 100% faster/slower or it was actually exactly the same speed and your mind played tricks on you.

[oleid]

I think so, at least I read about it on phoronix a while ago.

https://www.phoronix.com/news/Firefox-Clang-LTO-All-Platforms

This is the article. They even managed to get cross-language-LTO working using clang and rustc.

[Mario Junior]

What a joke this "mercury" is 😂

[Anux]

This is the article.

THX, 2018 is quiet a while time flies when your getting older.

[sophisticles]

I don't have a horse in the race as I don't use Firefox or Mercury, but continuing to use a bloated beast that labors under its own weight like Ubuntu for benchmarking browsers seems like a strange choice. I don't know if the results are applicable to anything I would use.

In what way is Ubuntu a "bloated beast that labors under its own weight" and what do you consider not a bloated beast?

[sophisticles]

They should really code name every release of Mercury as Freddy.

[avis]

The whole premise of AVX+PGO+LTO in a browser bringing 8-20% sounds unrealistic for me.

Javascript benchmarks cannot take advantage of AVX, and while AVX could in theory be a big benefit for graphics operations, most of those are usually already gpu-accelerated in modern browser versions.
LTO and PGO could help with Javascript and in general at other places where AVX doesn't make sense, but they rarely bring more than just 2-5%, so this up to 20% performance seems very dubious. Even if there is a code piece where they could bring "8-20%" (such as hashing or cryptography), that won't change the overall user experience as these are not the bottleneck. I'm not saying PGO and LTO are useless, every percent matters, but this here smells like snake-oil and over-hype.

But maybe most importantly, Firefox uses JIT to execute Javascript, so the speed of executing JS will not depend on GCC or Clang at all, but instead will solely depend on what bytecode the JS is compiled into by Firefox at runtime. GCC/Clang optimizations matter at most for how fast Firefox can start executing JS, but that is not what benchmarks usually measure.

And Michael's benchmarks in the current article perfectly demonstrate these points.

Official Firefox builds do use PGO+LTO (as evidenced by a slower Debian build) but not AVX, so this "special"/"optimized" build is not so useful.

[clippy]

Yes, it's true that Firefox ESR will give you better stability like any other LTS software. But no matter if it's Firefox ESR or the latest stable release, I don't understand why do Debian, Fedora and probably other distros refuse to build Firefox with Clang and insist on continue building it with gcc. I mean that's the very reason official Firefox builds by Mozilla are slightly faster than distro builds. Because with Clang you can have some browser related compiler optimizations that are impossible to achieve with gcc. I heard that Chrome is also built with Clang for this reason.

Fedora maintainers considered switching their Firefox build to Clang when upstream did: https://pagure.io/fesco/issue/2020
In the end, they stuck with GCC because Clang at the time didn't support some compiler hardening techniques that Fedora uses by default. AFAIU, building everything with GCC unless there's a very good reason not to is part of Fedora's packaging guidelines, and the promise of about 10% more performance didn't merit an exception.

[onlyLinuxLuvUBack]

Fedora maintainers considered switching their Firefox build to Clang when upstream did: https://pagure.io/fesco/issue/2020
In the end, they stuck with GCC because Clang at the time didn't support some compiler hardening techniques that Fedora uses by default. AFAIU, building everything with GCC unless there's a very good reason not to is part of Fedora's packaging guidelines, and the promise of about 10% more performance didn't merit an exception.

they just need to rewrite firefox in rust

[Iksf]

I found this very interesting thank you. I generally have also noticed forks of browsers claiming speed benefits are unable to deliver much gains over the main branch. However, very happy to see people try to find performance improvements even if mostly unsuccessful. Very cool to see the benefits shaping up in 118 alpha.