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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Iksf
    replied
    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.

    Leave a comment:


  • onlyLinuxLuvUBack
    replied
    Originally posted by clippy View Post

    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

    Leave a comment:


  • clippy
    replied
    Originally posted by user1 View Post

    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.

    Leave a comment:


  • avis
    replied
    Originally posted by ultimA View Post
    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.

    Leave a comment:


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

    Leave a comment:


  • sophisticles
    replied
    Originally posted by andyprough View Post
    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?

    Leave a comment:


  • Anux
    replied
    Originally posted by oleid View Post
    This is the article.
    THX, 2018 is quiet a while time flies when your getting older.

    Leave a comment:


  • Mario Junior
    replied
    What a joke this "mercury" is 😂

    Leave a comment:


  • oleid
    replied
    Originally posted by Anux View Post
    I think so, at least I read about it on phoronix a while ago.
    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


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

    Leave a comment:


  • Anux
    replied
    Originally posted by user1 View Post
    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.

    Leave a comment:

Working...
X