Expand using Profile-Guided Optimization (PGO) for MacPorts packages

[zamazan4ik (Alexander Zaitsev)]

Hi!

Now I am investigating Profile-Guided Optimization (PGO) effects on different kinds of software - all my current results are available at ​https://github.com/zamazan4ik/awesome-pgo. According to these results, enabling PGO can help with achieving better overall performance in many cases. I think expanding PGO usage for the MacPorts packages would be a good idea since it could help to achieve better software performance and lower battery usage.

### Profile-Guided Optimization (PGO)

PGO is already a well-known technique. All currently known PGO effects on performance can be found at ​https://github.com/zamazan4ik/awesome-pgo#pgo-showcases . Several OS distros already enabled PGO for some packages like GCC, Rustc, Chromium, Firefox, and others (it depends on each OS distro, of course).

I think we can try to expand PGO usage across MacPorts packages. I think we can start by enabling PGO at least for the following projects (these packages are already PGO-optimized in many OS distros):

• Compilers like Clang, Rust (rustc), and others
• Expand PGO usage for more LLVM tooling - [PGO benchmark](​https://github.com/llvm/llvm-project/issues/63486) like clang-format, Clangd, etc.
• Databases like SQLite
• Small utilities Difftastic - [PGO benchmark](​https://github.com/Wilfred/difftastic/issues/588)

I am sure it's possible to find more packages with upstream PGO support or for which enabling PGO could be an interesting option - all known for me PGO optimization results are available at ​https://github.com/zamazan4ik/awesome-pgo#pgo-showcases . As far as I know, CPython and SWI-Prolog are the only projects with enabled PGO in MacPorts.

### Additional optimization - Post Link Optimization (PLO)

Regarding Post Link Optimization (PLO), right now there are two main tools - LLVM BOLT and Google Propeller.

According to the Facebook Research Paper (​https://research.facebook.com/publications/bolt-a-practical-binary-optimizer-for-data-centers-and-beyond/), LLVM BOLT (​https://github.com/llvm/llvm-project/blob/main/bolt/README.md) helps with achieving better performance for various packages like compilers and interpreters. I think it would be a good idea to enable LLVM BOLT for some packages to deliver faster binaries for users (since Propeller is less stable right now in my opinion). Unfortunately, right now LLVM BOLT does not support the macOS platform (see ​https://github.com/llvm/llvm-project/issues/72205). If you are interested in using LLVM BOLT on macOS - please vote for adding macOS support to LLVM BOLT in the upstream.

Here I got some examples of how LLVM BOLT is already integrated into other projects:

• Rustc: ​https://github.com/rust-lang/rust/pull/116352
• CPython: ​https://github.com/python/cpython/pull/95908
• Pyston:
  • ​https://github.com/pyston/pyston#building
  • ​https://github.com/pyston/pyston/blob/pyston_main/Makefile#L200
• Clang: ​https://github.com/llvm/llvm-project/blob/main/clang/cmake/caches/BOLT.cmake

So at least for the projects above LLVM BOLT effects are tested and some preparations are already done in the upstream projects. In this case, it should be easier to enable BOLT for these packages.

For some projects right now there is ongoing work on integrating LLVM BOLT into the build scripts:

• Chromium: ​https://bugs.chromium.org/p/chromium/issues/detail?id=1163978
• Firefox: ​https://bugzilla.mozilla.org/show_bug.cgi?id=1789087
  • The same for Propeller (a LLVM BOLT alternative): ​https://bugzilla.mozilla.org/show_bug.cgi?id=1509314
• NodeJS: ​https://github.com/nodejs/node/issues/50379
• LDC: ​https://github.com/ldc-developers/ldc/issues/4228
• GCC: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112492

More about LLVM BOLT performance results for other projects can be found in:

• Rustc:
  • ​https://github.com/rust-lang/rust/pull/116352
  • ​https://www.reddit.com/r/rust/comments/y4w2kr/llvm_used_by_rustc_is_now_optimized_with_bolt_on/
• CPython: ​https://github.com/python/cpython/pull/95908
• YDB: ​https://github.com/ydb-platform/ydb/issues/140
• Clang:
  • [Slides](​https://llvm.org/devmtg/2022-11/slides/Lightning15-OptimizingClangWithBOLTUsingCMake.pdf)
  • [Results on building Clang](​https://github.com/ptr1337/llvm-bolt-scripts/blob/master/results.md)
  • [Linaro results](​https://android-review.linaro.org/plugins/gitiles/toolchain/llvm_android/+/f36c64eeddf531b7b1a144c40f61d6c9a78eee7a)
  • [on AMD 7950X3D](​https://github.com/llvm/llvm-project/issues/65010#issuecomment-1701255347)
• LDC: ​https://github.com/ldc-developers/ldc/issues/4228#issuecomment-1334499428
• NodeJS: ​https://aaupov.github.io/blog/2020/10/08/bolt-nodejs
• Chromium: ​https://aaupov.github.io/blog/2022/11/12/bolt-chromium
• MySQL, MongoDB, memcached, Verilator: ​https://people.ucsc.edu/~hlitz/papers/ocolos.pdf

Some OS already using LLVM BOLT in their build scripts - [check](​https://github.com/getsolus/packages/blob/main/packages/l/llvm/package.yml#L116) Clang recipe in Solus.

With this issue, I want to start a discussion about providing more advanced optimizations to the MacPorts packages before actual issue creation. I don't create an issue per project (like "Enable BOLT for Clang", "Enable PGO for GCC", etc.) since I think first we need to discuss the approach. If we agree on expanding PGO usage for some packages, then we can create an additional issue (and use this issue as a meta issue). In this issue, we can discuss approaches regarding PGO and PLO.

[ryandesign (Ryan Carsten Schmidt)]

The mailing list is the traditional place to have discussions...

[zamazan4ik (Alexander Zaitsev)]

Sure! I can write to the mailing list.

[ryandesign (Ryan Carsten Schmidt)]

I note that you have also opened the same discussion with Homebrew at ​https://github.com/orgs/Homebrew/discussions/4902.

[zamazan4ik (Alexander Zaitsev)]

Yes, you are right. Since every project has a different opinion about such things as enabling more aggressive optimizations, I decided to create similar issues on a per-project basis. If you think MacPorts and Homebrew projects have similar visions about this question - we can continue the discussion in Homebrew.