Firefox nightly is now built with clang LTO on all platforms | Hacker News Reader

Firefox nightly is now built with clang LTO on all platforms

glandium.org

122 pointsrbanffy37 comments

Some might wonder what LTO and PGO mean (I did). LTO: Link time optimization, PGO: Profile-guided optimization.

> You might wonder if we tried LTO with GCC, or tried upgrading to GCC 8.x. As a matter of fact, I did. Enabling LTO turned up linker errors

So... they just gave up on gcc, and then per the remainder of the blog post spent "3 months" fighting linker behavior to get LTO working on clang? That seems like a surprising asymmetry, and makes me wonder if the reported performance gains weren't the real reason for the switch.

> Considering the expected future advantages from using clang (cross-language inlining with Rust, consistency between platforms), it seemed a better deal to switch to clang than to try to address those issues.

No, they anticipated switching over to clang in the future so rather than spend "3 months" fighting GCC's linker then do it all over again switching to clang, they just switched.

> So... they just gave up on gcc, and then per the remainder of the blog post spent "3 months" fighting linker behavior to get LTO working on clang?

Given that they're trying to align their C++ and Rust build tools -- the latter being based on LLVM -- the lack of interest in solving issues experienced with GCC is understandable. Also, given the complexity of the application and the platform diversity involved spending only "3 months" on such troubles is heroic performance.

The primary change wasn't away from GCC, it was away from MSVC.

https://groups.google.com/forum/m/#!topic/mozilla.dev.platfo...

The blog post does also say: "Considering the expected future advantages from using clang (cross-language inlining with Rust, consistency between platforms), it seemed a better deal to switch to clang than to try to address those issues."

Clang LTO works between Rust and C++ - GCC can't do that.

will work; it’s in-progress, but not ready for the big times yet, as far as I know https://github.com/rust-lang/rust/issues/49879

Here is the source blog post (and a better link imho):

https://glandium.org/blog/?p=3888

Thanks! We've updated the link from https://www.phoronix.com/scan.php?page=news_item&px=Firefox-....

I wonder how this compares to a native GCC build. I always build Firefox myself (as I do with everything) and is always been noticeably faster than the binary. I hope this doesn't mean there will be problems doing GCC builds in the future.

The article mentions that GCC is still remaining a supported compiler and that there are automated builds in their CI to ensure that it stays working.

Just of curiosity, what OS do you run? Why do you build everything from source?

Not OP, but I compile everything other than my Steam games from source - I run Gentoo.

I use Gentoo.

Do you do -march=native?

Yep.

When did they switch to Clang? The about:buildconfig of my Developer Edition (Ubuntu) shows GCC 6.4.0, without -flto obviously.

On a related note, I wish they would add the information about the Rust compiler used to compile the components written in Rust.

Probably this refers only to the pre-compiled builds offered by Mozilla? The distribution packagers build Firefox from source before pushing them to the repository so it would make sense to use the default compiler for the distribution.

On a relevant note, is there any linux distribution that defaults to clang instead of GCC? Up until a couple of years ago the kernel would not even build with clang.

IIRC some article claimed OpenSUSE would now use clang with lto. That must have been about a month or two ago.

Do you mean which version they use (e.g. 1.28, stable, beta, nightly, etc.)? They have a dedicated page for required versions: https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox

The tables are confusing, but it seems like they require the most recent stable as of 2 weeks before the firefox release.

This is for Mozilla's own builds. If you add a .desktop file¹, they work great, and they include a built-in updater (like the updater on Mac or Win).

1: https://blog.nightly.mozilla.org/2018/01/22/335/

> and they include a built-in updater (like the updater on Mac or Win)

Oh joy! Sign me up!

I guess having the app update itself may have some appeal for LTS and enterprise distros, where you cannot get the latest-greatest release from the distro vendor. On something like Arch Linux, it's pretty pointless and actually counter-productive: By the time, the package lands in the stable channel of the distro, you know that it works well with all your system libraries because someone tested it.

It's all in the first 3 sentences of the article.

> You might have read that Mozilla recently switched Windows builds to clang-cl... As of next nightly (as of writing, obviously), all tier-1 platforms are now built with clang with LTO enabled.

What I meant is, when did they start the switch, and which versions have already switched.

Nightly is based off of mozilla-central, our trunk.

When Nightly switches, that means that the version currently being developed (64), is the first version that has been switched.

Fx63 (on Beta and Developer Edition) is on track to ship with clang-cl as the Windows compiler too.

Windows builds were switched to clang back in July before Linux. MacOS was already using it.

Developer Edition builds are based on their current Beta version (Fx63 at this point) and this change just landed on Nightly, which is tracking Fx64.

Wait they just gave on GCC's because they could not get linker optimizations working... However, they are surprised Clang with linker optimizations was faster than GCC without...

I failed to mention it originally, but updated the post with this: it's worth noting that comparing GCC+PGO vs. clang+LTO or GCC+PGO vs. clang+PGO was a win for clang overall in both cases, although GCC was winning on a few benchmarks. If I remember correctly, clang without PGO/LTO was also winning against GCC without PGO.

But that's still with an ancient GCC version compared to a newer Clang, right?

I would not say ancient, but yea GCC 6 is getting old. I know GCC has had additional optimizations added since then. Although, I am curious how GCC 7+ was breaking binary compatibility? Calling convention, name mangling what?

Using symbols from newer libgcc and libstdc++.

edit: Removed

Right at the very top of the article:

> This doesn’t mean GCC is being unsupported. As a matter of fact, we still have automated jobs using GCC for some static analysis, and we also have jobs ensuring everything still builds with a baseline of GCC 6.x.

Did you even read it? Also ~10% improvement in speeds is worth switching, IMO.

Reply on news.ycombinator.com