9 ms·

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

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.

mintplant 6y ago
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/pgo.html https://firefox-source-docs.mozilla.org/build/buildsystem/pg...
- loeg 6y ago
  Mozilla could publish their profile data for a given release image.
  - glandium 6y ago
    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)
- CalChris 6y ago
  Given PGO and branch prediction, has anyone tested whether turning off MOZ_LIKELY/MOZ_UNLIKELY makes any difference?
loeg 6y ago
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.
- rurban 6y ago
  Nowadays you are using perf profiles, and then use this with autofdo. The old -fprofile-use is not good enough and needs two steps.
wyldfire 6y ago
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.
- brandmeyer 6y ago
  Also hot/cold partitioning. Keeping cold code code away from hot code can help L1I cache utilization, iTLB utilization, Operating system page-out, etc.
1f60c 6y ago
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.
rurban 6y ago
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.

mintplant 6y ago

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/pgo.html https://firefox-source-docs.mozilla.org/build/buildsystem/pg...

loeg 6y ago
Mozilla could publish their profile data for a given release image.
- glandium 6y ago
  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)
CalChris 6y ago
Given PGO and branch prediction, has anyone tested whether turning off MOZ_LIKELY/MOZ_UNLIKELY makes any difference?

loeg 6y ago

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.

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

wyldfire 6y ago

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.

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

1f60c 6y ago

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.

rurban 6y ago

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.