Hacker News Reader

Comment by mintplant | Hacker News Reader

Firefox has done this since forever. It's why official builds will generally be faster than compiling from scratch yourself. I'm surprised Chrome wasn't already taking advantage of PGO.

View on HN

Firefox started using PGO on Windows in Firefox in 2008 [1], Android last year [2], and macOS earlier this year [3]. Firefox uses PGO on Linux, but I don't remember when it was enabled.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=418865

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=632954

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1604578

/offtopic

The all-new Firefox for Android (codename Daylight) is lightening fast, and perceptibly seems on-par with the Chrome for Android in terms of responsiveness.

What stumps me is Chrome for Android is 3.8MB whereas Firefox Daylight is upwards of 40MB.

Chrome's engine is built into Android, whereas the engine Firefox uses is not and thus has to be shipped with it.

Not sure if they will keep this edge given all the loss of talent.

I haven't looked at what Google does recently but you're likely getting most of Chrome in a separate package (e.g. the system WebView). Chrome and Firefox are of compareble size IIRC (56MB vs 65MB)

What's sad is they only support very few selected Add Ons.

>It's why official builds will generally be faster than compiling from scratch yourself.

Would it be possible for Google to publish the profile data along with the source code to enable those who compile from scratch to have these same optimizations?

>I'm surprised Chrome wasn't already taking advantage of PGO.

They have been on windows since M53 (released in 2016), but this seems to be a better implementation and it's now for MacOS as well now.

Is M85 the first Chrome Windows release done with Clang, as opposed to MSVC? I haven't been following the Windows side of it.

Great question! Anyone have this answer?

Chrome M64 was the first shipping version built with Clang on Windows: http://web.archive.org/web/20200125010517/http://blog.llvm.o...

Thanks. So Chrome on Windows had MSVC PGO from 53-63, but lost PGO from 64-84.

Can you explain this because the article says:

  It is rolling out with Chrome M85 on Mac and Windows.

Never mind. This [1] says:

  Starting in Chrome 53, Chrome has started using
  Microsoft’s Profile Guided Optimization (PGO)
  technology to make Chrome up to 15% faster
  on Windows.

This strongly implies Google was using MSVC for the M53 build.

[1] https://blog.chromium.org/2016/10/making-chrome-on-windows-f...

From the article: "PGO was initially introduced in M53 for Chrome on Windows using Microsoft Visual C++ (MSVC) […] In M85, we are rolling out PGO on Mac and Windows using Clang."

So it sounds like they've been using PGO for a while using MSVC, and now they've started using PGO with Clang.

> Would it be possible for Google to publish the profile data

They do.

https://chromium.googlesource.com/chromium/src.git/+/master/...

Wouldn't PGO only work with the exact source code, flags, compiler version, etc... used by google ? At which point you'll end up with the exact same binary than Google's too

I'm surprised that there isn't a way to do PGO when compiling from scratch. A way of telling the compiler exactly what parts are, but build it into the codebase so that one could get the best of both worlds.

You can pass a PGO flag to the build system [0], but IIRC from when I was there last, Mozilla puts some serious machine hours into PGO cycles for each release and that isn't easy to replicate as an individual developer. The profiling captures things which are very specific to the actual build being optimized, so inlining that information into the codebase wouldn't be so helpful. Though there are already static optimization hints spread throughout the code (off the top of my head, MOZ_LIKELY/MOZ_UNLIKELY for marking conditionals).

[0] https://firefox-source-docs.mozilla.org/build/buildsystem/pg...

Mozilla could publish their profile data for a given release image.

They are public, but you have to know where to look. I do think they should be published alongside the builds on archive.mozilla.org. (disclaimer: I work for Mozilla)

Given PGO and branch prediction, has anyone tested whether turning off MOZ_LIKELY/MOZ_UNLIKELY makes any difference?

If someone can give you the PGO profile data from the exact same compiler and sources, you can do -fprofile-use (PGO) on subsequent builds.

Nowadays you are using perf profiles, and then use this with autofdo. The old -fprofile-use is not good enough and needs two steps.

PGO guides inlining and branch prediction IIRC. You can give static hints about each of these. But the hints aren't on a continuum like they are with PGO. So finding an optimal balance for these will be harder. Also you have to maintain these hints. So if you were somehow giving hints with a hotness ratio in the source it would be impossible to maintain and keep it accurate.

Also hot/cold partitioning. Keeping cold code code away from hot code can help L1I cache utilization, iTLB utilization, Operating system page-out, etc.

This isn't the same, but some compilers have support for macros that tell it which branches are more likely to be taken than others, and in C++20, it's even a language feature.

The G stands for guide. You need a testsuite to create a guided profile to optimize the branch hints.

Normally there's a simple make target, like chrome.pgo to create the initial binary chrome, run the testsuite with pgo or better autofdo via perf and from this create the optimized chrome.pgo. using Facebook's bolt is even better.

I have no idea about Google's byzantinian bazel tool. With make it's a simple target which automates these steps.

I do PROFILE=on for my own www/firefox FreeBSD package builds too, but it does make it take twice as long. https://www.freshports.org/www/firefox

Chrome's been doing it for a long time too, since version 53.

It's going to take a LOT of convincing to get me to use Chrome. I don't trust an ad company as my internet browser or phone OS anymore.

Not a glowing review of firefox lol.

And yet, Chrome has always feeled snappier and faster.

Chrome adopted multi core far sooner. A great if lengthy treatment here

https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...

Reply on news.ycombinator.com