Posted by Chris Wailes – Senior Software program Engineer
The efficiency, security, and developer productiveness offered by Rust has led to speedy adoption within the Android Platform. Since slower construct instances are a priority when utilizing Rust, notably inside an enormous venture like Android, we have labored to ship the quickest model of the Rust toolchain that we are able to. To do that we leverage a number of types of profiling and optimization, in addition to tuning C/C++, linker, and Rust flags. A lot of what I’m about to explain is much like the construct course of for the official releases of the Rust toolchain, however tailor-made for the particular wants of the Android codebase. I hope that this put up will probably be typically informative and, in case you are a maintainer of a Rust toolchain, could make your life simpler.
Android’s Compilers
Whereas Android is actually not distinctive in its want for a performant cross-compiling toolchain this reality, mixed with the massive variety of each day Android construct invocations, implies that we should fastidiously steadiness tradeoffs between the time it takes to construct a toolchain, the toolchain’s dimension, and the produced compiler’s efficiency.
Our Construct Course of
To be clear, the optimizations listed under are additionally current within the variations of rustc which are obtained utilizing rustup. What differentiates the Android toolchain from the official releases, in addition to the provenance, are the cross-compilation targets obtainable and the codebase used for profiling. All efficiency numbers listed under are the time it takes to construct the Rust parts of an Android picture and might not be reflective of the speedup when compiling different codebases with our toolchain.
Codegen Items (CGU1)
When Rust compiles a crate it can break it into some variety of code era models. Every unbiased chunk of code is generated and optimized concurrently after which later re-combined. This strategy permits LLVM to course of every code era unit individually and improves compile time however can scale back the efficiency of the generated code. A few of this efficiency could be recovered through the usage of Hyperlink Time Optimization (LTO), however this isn’t assured to realize the identical efficiency as if the crate had been compiled in a single codegen unit.
To reveal as many alternatives for optimization as potential and guarantee reproducible builds we add the -C codegen-units=1 choice to the RUSTFLAGS atmosphere variable. This reduces the scale of the toolchain by ~5.5% whereas rising efficiency by ~1.8%.
Remember that setting this feature will decelerate the time it takes to construct the toolchain by ~2x (measured on our workstations).
GC Sections
Many initiatives, together with the Rust toolchain, have features, lessons, and even whole namespaces that aren’t wanted in sure contexts. The most secure and best possibility is to go away these code objects within the remaining product. This may improve code dimension and should lower efficiency (because of caching and structure points), but it surely ought to by no means produce a miscompiled or mislinked binary.
It’s potential, nevertheless, to ask the linker to take away code objects that aren’t transitively referenced from the essential()operate utilizing the –gc-sections linker argument. The linker can solely function on a section-basis, so, if any object in a bit is referenced, your entire part have to be retained. That is why additionally it is frequent to cross the -ffunction-sections and -fdata-sections choices to the compiler or code era backend. This may make sure that every code object is given an unbiased part, thus permitting the linker’s rubbish assortment cross to gather objects individually.
This is likely one of the first optimizations we carried out and, on the time, it produced important dimension financial savings (on the order of 100s of MiBs). Nevertheless, most of those features have been subsumed by these created from setting -C codegen-units=1 when they’re utilized in mixture and there’s now no distinction between the 2 produced toolchains in dimension or efficiency. Nevertheless, as a result of further overhead, we don’t all the time use CGU1 when constructing the toolchain. When testing for correctness the ultimate pace of the compiler is much less vital and, as such, we permit the toolchain to be constructed with the default variety of codegen models. In these conditions we nonetheless run part GC throughout linking because it yields some efficiency and dimension advantages at a really low value.
Hyperlink-Time Optimization (LTO)
A compiler can solely optimize the features and information it might probably see. Constructing a library or executable from unbiased object information or libraries can pace up compilation however at the price of optimizations that depend upon info that’s solely obtainable when the ultimate binary is assembled. Hyperlink-Time Optimization provides the compiler one other alternative to research and modify the binary throughout linking.
For the Android Rust toolchain we carry out skinny LTO on each the C++ code in LLVM and the Rust code that makes up the Rust compiler and instruments. As a result of the IR emitted by our clang is likely to be a special model than the IR emitted by rustc we are able to’t carry out cross-language LTO or statically hyperlink towards libLLVM. The efficiency features from utilizing an LTO optimized shared library are higher than these from utilizing a non-LTO optimized static library nevertheless, so we’ve opted to make use of shared linking.
Utilizing CGU1, GC sections, and LTO produces a speedup of ~7.7% and dimension enchancment of ~5.4% over the baseline. This works out to a speedup of ~6% over the earlier stage within the pipeline due solely to LTO.
Profile-Guided Optimization (PGO)
Command line arguments, atmosphere variables, and the contents of information can all affect how a program executes. Some blocks of code is likely to be used steadily whereas different branches and features could solely be used when an error happens. By profiling an software because it executes we are able to acquire information on how typically these code blocks are executed. This information can then be used to information optimizations when recompiling this system.
We use instrumented binaries to gather profiles from each constructing the Rust toolchain itself and from constructing the Rust parts of Android photos for x86_64, aarch64, and riscv64. These 4 profiles are then mixed and the toolchain is recompiled with profile-guided optimizations.
Because of this, the toolchain achieves a ~19.8% speedup and 5.3% discount in dimension over the baseline compiler. It is a 13.2% speedup over the earlier stage within the compiler.
BOLT: Binary Optimization and Format Device
Even with LTO enabled the linker continues to be answerable for the structure of the ultimate binary. As a result of it isn’t being guided by any profiling info the linker may by chance place a operate that’s steadily referred to as (scorching) subsequent to a operate that’s hardly ever referred to as (chilly). When the recent operate is later referred to as all features on the identical reminiscence web page will probably be loaded. The chilly features are actually taking on area that could possibly be allotted to different scorching features, thus forcing the extra pages that do include these features to be loaded.
BOLT mitigates this downside through the use of an extra set of layout-focused profiling info to re-organize features and information. For the needs of dashing up rustc we profiled libLLVM, libstd, and librustc_driver, that are the compiler’s essential dependencies. These libraries are then BOLT optimized utilizing the next choices:
--peepholes=all
--data=<path-to-profile>
--reorder-blocks=ext-tsp
–-reorder-functions=hfsort
--split-functions
--split-all-cold
--split-eh
--dyno-stats
Any extra libraries matching lib/*.so are optimized with out profiles utilizing solely –peepholes=all.
Making use of BOLT to our toolchain produces a speedup over the baseline compiler of ~24.7% at a dimension improve of ~10.9%. It is a speedup of ~6.1% over the PGOed compiler with out BOLT.
In case you are involved in utilizing BOLT in your individual venture/construct I provide these two bits of recommendation: 1) you’ll must emit extra relocation info into your binaries utilizing the -Wl,–emit-relocs linker argument and a couple of) use the identical enter library when invoking BOLT to provide the instrumented and the optimized variations.
Conclusion
By compiling as a single code era unit, rubbish gathering our information objects, performing each link-time and profile-guided optimizations, and leveraging the BOLT instrument we had been in a position to pace up the time it takes to compile the Rust parts of Android by 24.8%. For each 50k Android builds per day run in our CI infrastructure we save ~10K hours of serial execution.
Our trade is just not one to face nonetheless and there’ll certainly be one other instrument and one other set of profiles in want of gathering within the close to future. Till then we’ll proceed making incremental enhancements looking for extra efficiency. Blissful coding!
