I'd love to understand the tradeoffs here. If it's just compiler optimizations, why wouldn't Mozilla turn them on themselves? They've done huge man-century performance projects, I'd be surprised they'd let such low-hanging fruit hang without a good reason.
They would have to compile for a generic x64 CPU to ensure compatibility with older CPUs. By targeting a specific CPU or `march=native` the compiler may avail of SIMD features more where appropriate. Whether those types of optimisations are relevant for a browser is up for debate.
Main thing is building for zen2 gives you a binary that can't run on a core2 x86-64 interpreter.
Secondary is that compiler optimisations are prone to creating binaries that don't work like the less optimised version. Not everyone has the hardline "if it changes behaviour it's a bug, not an optimisation" perspective. Those that do still make mistakes.
LTO is really good at detecting aliasing violations between translation units which were previously benign but can now be "optimised" into ruin.
PGO was originally changing branch probabilities which should be harmless but I haven't looked recently, it might be more aggressive now.
But Firefox can already do LTO and PGO? I thought that firefox let the underlying cryptography library do its work, and those are already using AVX and AES as well.
From the graphics and other things it appears it doesn't even appear in benchmarks when comparing with the same version it's forked and also that the performance gains in each version in Firefox itself make a much better improvements with Firefox 118 being the highlight in the benchmarks evaluated.
I'd be shocked if this helps significantly. My understanding is all major browsers are shipping builds with LTO and PGO already. We investigated whether there is any obvious performance left on the table in another engine (WebKit) and came to the quick conclusion that there just isn't much that you can do this easily. (Which, to be honest, is not entirely surprising.)
This is a fairly common cognitive dissonance I see in technology – preferring small developers/publishers/etc with essentially no basis for trust over big companies who are subject to legislation all around the world and have strong compliance procedures, auditing, security assessments, chains of trust, etc.
The latter is more secure in almost every case, in almost every way you can analyse the problem, but at a human level it's easier to trust one person whose name you know over a company where you can't point to any specific individual.
When you know someone personally then perhaps this is a reasonable trade-off to make, but "on the internet nobody knows you're a dog"[1]. People form parasocial relationships with individuals, movements, influencers, etc, and really there's not much to trust about them.
Not that I could ever tell - I did it years ago for Waterfox but dropped it after finding no performance improvements after migrating away from Intel's C++ compiler toolchain.
LibreWolf, AFAIK, has been hyper aggressive on privacy preferences (to the detriment of a useable web sometimes) and is its USP.
Coming from years of experience doing this with Waterfox - I would not recommend using anything like this.
I used to be quite aggressive with compiler optimisations - but all you are really doing is introducing instability and more often than not, performance regressions.
For the latest release, I actually started including polyhedral optimisation provided by the LLVM Polly project, but the effort resulted in essentially 0 performance gain. It was to be expected, as polly isn't really going to net general performance improvements, especially with the type of work a browser is doing.
It's also VERY easy to mislead yourself when adding these optimisations by getting a good run on a benchmark once or twice, yet you could try another run and get a different result. I am guilty of this myself, it took a long time to realise the mistakes I was making.
The reality was, I found, running on fresh device in comparison with Firefox, was almost no difference. The majority of performance improvements came from the engineering effort put in by Mozilla themselves and they are VERY good at that. The devs are also conscious of the available compiler optimisations and make a very good effort to include any that make a difference.
> Compiler optimizations include AVX, AES, LTO and PGO.
Firefox already does LTO and PGO, and for majority of the code, where AVX is beneficial, it is already included with code dispatch if the CPU supports it (for example with media codecs). The same goes for AES in the NSS library.
Does that mean you can't get Clang/LLVM to generate AVX instructions? Yes, I'm sure it does. Does it actually make a meaningful difference? No. Not that I've found from years of doing this and eventually just abandoning it.
The only time I ever saw big, proper gains from compiler optimisation alone was when I was compiling Waterfox with Intel's C++ compiler and using auto dispatching with the Qax [1] flag. Intel were doing some magic there. But the effort to get the Firefox codebase compiled with it was nothing short of sisyphean and essentially an exercise in masochism.
21 comments
[ 2.6 ms ] story [ 23.1 ms ] threadSecondary is that compiler optimisations are prone to creating binaries that don't work like the less optimised version. Not everyone has the hardline "if it changes behaviour it's a bug, not an optimisation" perspective. Those that do still make mistakes.
LTO is really good at detecting aliasing violations between translation units which were previously benign but can now be "optimised" into ruin.
PGO was originally changing branch probabilities which should be harmless but I haven't looked recently, it might be more aggressive now.
The results were underwhelming.
The latter is more secure in almost every case, in almost every way you can analyse the problem, but at a human level it's easier to trust one person whose name you know over a company where you can't point to any specific individual.
When you know someone personally then perhaps this is a reasonable trade-off to make, but "on the internet nobody knows you're a dog"[1]. People form parasocial relationships with individuals, movements, influencers, etc, and really there's not much to trust about them.
[1]: https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_...
An individual may be more likely to agree with your own definition of "malicious".
LibreWolf, AFAIK, has been hyper aggressive on privacy preferences (to the detriment of a useable web sometimes) and is its USP.
I used to be quite aggressive with compiler optimisations - but all you are really doing is introducing instability and more often than not, performance regressions.
For the latest release, I actually started including polyhedral optimisation provided by the LLVM Polly project, but the effort resulted in essentially 0 performance gain. It was to be expected, as polly isn't really going to net general performance improvements, especially with the type of work a browser is doing.
It's also VERY easy to mislead yourself when adding these optimisations by getting a good run on a benchmark once or twice, yet you could try another run and get a different result. I am guilty of this myself, it took a long time to realise the mistakes I was making.
The reality was, I found, running on fresh device in comparison with Firefox, was almost no difference. The majority of performance improvements came from the engineering effort put in by Mozilla themselves and they are VERY good at that. The devs are also conscious of the available compiler optimisations and make a very good effort to include any that make a difference.
> Compiler optimizations include AVX, AES, LTO and PGO.
Firefox already does LTO and PGO, and for majority of the code, where AVX is beneficial, it is already included with code dispatch if the CPU supports it (for example with media codecs). The same goes for AES in the NSS library.
Does that mean you can't get Clang/LLVM to generate AVX instructions? Yes, I'm sure it does. Does it actually make a meaningful difference? No. Not that I've found from years of doing this and eventually just abandoning it.
The only time I ever saw big, proper gains from compiler optimisation alone was when I was compiling Waterfox with Intel's C++ compiler and using auto dispatching with the Qax [1] flag. Intel were doing some magic there. But the effort to get the Firefox codebase compiled with it was nothing short of sisyphean and essentially an exercise in masochism.
[1] https://www.intel.com/content/www/us/en/docs/cpp-compiler/de...