Google Propeller Squeezes Extra Performance from Large-Scale LLVM Binaries

Write for InfoQ

Google Propeller is able to improve the performance of LLVM binaries by relinking and optimizing them based on a profile of their behaviour at runtime. Propeller can bring 2-9% improvements on key performance benchmarks for binaries that were previously highly optimized by LLVM, say Google engineers.

Propeller's aim is to create a new binary from the one you profiled after applying a number of transformations to its layout. In short, what you do to take advantage of Propeller is run your program, and compile using a specific flag to gather metrics about its behaviour and performance at runtime. Then, you feed that data into Propeller to have it transform your binary layout to extract the maximum performance out of it. This is what is called profile-guided optimization, which is not to be confused with dynamic optimization, such as that provided by Dynamo and other similar tools, which optimize a system at runtime.

Initially announced on the LLVM-dev mailing list in September 2019, Propeller is inspired by Facebook BOLT, another recent LLVM-based profile-based relinker, but uses a different approach that lends itself to be used with distributed build systems and scales better with the binary size.

In particular, Google engineers found that while BOLT grants significant runtime performance gains, its monolithic, single-step architecture leads to required memory and time exploding for binaries with a ~300MB segment size. Now, while 300MB binaries are admittedly large and not that many developers could need to optimize such large systems, Propeller seems to provide a couple of additional benefits over BOLT. Specifically, Propeller is designed around a two-step optimization process, where the first step can be distributed across parallel workers. In contrast to this, BOLT is implemented as a single process that directly works on the input binary in one go.

Additionally, Propeller should be much better than BOLT with incremental builds. This is possible because when small source changes do not modify the profile information significantly, Propeller may do a better job at identifying those parts of the binary that needs to be re-processed.

To put things in perspective, LLVM is already able to do both link-time optimization (LTO) and profile-guided optimization (PGO), alongside other major compilers. What tools like BOLT or Propeller do to further improve over LLVM optimizations is a more aggressive use of profiled data, favouring the use of exact profile data over approximations.

If you are interested in the details of how Propeller works, Google has made available an RFC thoroughly documenting how Propeller works (PDF) and how it can be used starting with pulling its source code from GitHub and compiling it.

EDITORIAL NOTE: In a first version of this article, we incorrectly overstated BOLT's inhability to cope with code changes due to the fact that even minor changes to the profile would invalidate it altogether and require the whole optimization process to start over. Although this statement was based on information from Google's Propeller RFC at the time of this writing, it was inaccurate. BOLT is indeed able to deal with code changes to some extent and the original sentence was therefore removed. Thanks to Google engineer Sriraman Tallam for this clarification.

Related Topics:

• Development
• Performance
• C
• C++
• LLVM
• Optimization

We protect your privacy.