Evaluate Profile-Guided Optimization (PGO) and LLVM BOLT

[zamazan4ik]

Hi!

I did a lot of Profile-Guided Optimization (PGO) benchmarks recently on different kinds of software (including many compilers and compiler-like projects like Clang, Rustc, Clangd, clang-tidy, etc.) - all currently available results are located at https://github.com/zamazan4ik/awesome-pgo . According to the tests, PGO usually helps a lot for compiler-like workloads. I think testing PGO would be a good idea for Enso tooling ecosystem (since part of the project is written in Rust that supports PGO out of the box with rustc compiler).

I can suggest to do the following things:

• Evaluate PGO on Enso tooling
• If it benefits Enso - add a note to the Enso documentation (wiki?) about building with PGO. In this case, users and maintainers who build their own Enso binaries will be aware of PGO as an additional way to optimize the project
• Optimize provided by Enso project binaries on the CI (like it's already done for other projects like Rustc), if any
• After that, I suggest trying to apply LLVM BOLT as an additional post-PGO step. Rustc already does it on some platforms

For the Rust projects, I suggest PGO optimizing with cargo-pgo.

I see, that some parts of Enso are Rust libraries. For them could be trickier to collect proper PGO profiles, if they are not executed directly from Rust-based binaries. If you want to optimize such libraries as well, maybe will be a good idea to write a wrapping binary or implement some Rust-native bench suite (because from the benchmarks profiles can be easily generated with cargo pgo bench command).

I want to highlight - this issue is not about adding PGO into the Enso language itself. It's about optimizing Enso tooling with PGO like compiler, language server, etc.

[farmaazon]

Hi @zamazan4ik!

Thanks for the information, it indeed looks interesting.

I see, that some parts of Enso are Rust libraries. For them could be trickier to collect proper PGO profiles, if they are not executed directly from Rust-based binaries. If you want to optimize such libraries as well, maybe will be a good idea to write a wrapping binary or implement some Rust-native bench suite (because from the benchmarks profiles can be easily generated with cargo pgo bench command).

Indeed, almost everything is actually a library crate, as we compile it to WASM and use from JS electron application. In fact, we are during a process of replacing most of those rust code to native ts code, but we still keep some WASM libraries - could those be optimized as well?

I guess we could compile those libraries natively and use them in some wrapping binary - will the results of such profiling work when compiled to WASM? Do you know if anyone tested such scenario?

[zamazan4ik]

could those be optimized as well?

I think yes.

I guess we could compile those libraries natively and use them in some wrapping binary - will the results of such profiling work when compiled to WASM? Do you know if anyone tested such scenario?

Yes, the profiles will work fine. I do not know anyone who used profiles from "usual" native builds for optimizing WASM builds but it's completely fine to do it in Rust! I do not think that your hot/cold paths differ a lot between native and WASM modes.