Go to file
bors 33259d9797 auto merge of #13833 : alexcrichton/rust/ffunction-sections, r=thestinger
The compiler has previously been producing binaries on the order of 1.8MB for
hello world programs "fn main() {}". This is largely a result of the compilation
model used by compiling entire libraries into a single object file and because
static linking is favored by default.

When linking, linkers will pull in the entire contents of an object file if any
symbol from the object file is used. This means that if any symbol from a rust
library is used, the entire library is pulled in unconditionally, regardless of
whether the library is used or not.

Traditional C/C++ projects do not normally encounter these large executable
problems because their archives (rust's rlibs) are composed of many objects.
Because of this, linkers can eliminate entire objects from being in the final
executable. With rustc, however, the linker does not have the opportunity to
leave out entire object files.

In order to get similar benefits from dead code stripping at link time, this
commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as
well as passing --gc-sections to the linker *by default*. This means that each
function and each global will be placed into its own section, allowing the
linker to GC all unused functions and data symbols.

By enabling these flags, rust is able to generate much smaller binaries default.
On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in
size). The output size of dynamic libraries remained constant, but the output
size of rlibs increased, as seen below:

    libarena       -  2.27% bigger
    libcollections -  0.64% bigger
    libflate       -  0.85% bigger
    libfourcc      - 14.67% bigger
    libgetopts     -  4.52% bigger
    libglob        -  2.74% bigger
    libgreen       -  9.68% bigger
    libhexfloat    - 13.68% bigger
    liblibc        - 10.79% bigger
    liblog         - 10.95% bigger
    libnative      -  8.34% bigger
    libnum         -  2.31% bigger
    librand        -  1.71% bigger
    libregex       -  6.43% bigger
    librustc       -  4.21% bigger
    librustdoc     -  8.98% bigger
    librustuv      -  4.11% bigger
    libsemver      -  2.68% bigger
    libserialize   -  1.92% bigger
    libstd         -  3.59% bigger
    libsync        -  3.96% bigger
    libsyntax      -  4.96% bigger
    libterm        - 13.96% bigger
    libtest        -  6.03% bigger
    libtime        -  2.86% bigger
    liburl         -  6.59% bigger
    libuuid        -  4.70% bigger
    libworkcache   -  8.44% bigger

This increase in size is a result of encoding many more section names into each
object file (rlib). These increases are moderate enough that this change seems
worthwhile to me, due to the drastic improvements seen in the final artifacts.
The overall increase of the stage2 target folder (not the size of an install)
went from 337MB to 348MB (3% increase).

Additionally, linking is generally slower when executed with all these new
sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the
`rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three
megabytes are shaved off the binary. I found this increase in link time to be
acceptable relative to the benefits of code size gained.

This commit only enables --gc-sections for *executables*, not dynamic libraries.
LLVM does all the heavy lifting when producing an object file for a dynamic
library, so there is little else for the linker to do (remember that we only
have one object file).

I conducted similar experiments by putting a *module's* functions and data
symbols into its own section (granularity moved to a module level instead of a
function/static level). The size benefits of a hello world were seen to be on
the order of 400K rather than 1.2MB. It seemed that enough benefit was gained
using ffunction-sections that this route was less desirable, despite the lesser
increases in binary rlib size.
2014-04-29 16:16:46 -07:00
man
mk mk: Depend on regex_macros for tests appropriately 2014-04-29 08:55:40 -07:00
src auto merge of #13833 : alexcrichton/rust/ffunction-sections, r=thestinger 2014-04-29 16:16:46 -07:00
.gitattributes
.gitignore
.gitmodules
.mailmap
.travis.yml
AUTHORS.txt
configure
CONTRIBUTING.md
COPYRIGHT
LICENSE-APACHE
LICENSE-MIT
Makefile.in
README.md Add git to README.md dependency list because configure requires it 2014-04-18 14:50:31 -04:00
RELEASES.txt

The Rust Programming Language

This is a compiler for Rust, including standard libraries, tools and documentation.

Quick Start

  1. Download a binary installer for your platform.
  2. Read the tutorial.
  3. Enjoy!

Note: Windows users can read the detailed getting started notes on the wiki.

Building from Source

  1. Make sure you have installed the dependencies:

    • g++ 4.4 or clang++ 3.x
    • python 2.6 or later (but not 3.x)
    • perl 5.0 or later
    • GNU make 3.81 or later
    • curl
    • git
  2. Download and build Rust:

    You can either download a tarball or build directly from the repo.

    To build from the tarball do:

     $ curl -O http://static.rust-lang.org/dist/rust-nightly.tar.gz
     $ tar -xzf rust-nightly.tar.gz
     $ cd rust-nightly
    

    Or to build from the repo do:

     $ git clone https://github.com/mozilla/rust.git
     $ cd rust
    

    Now that you have Rust's source code, you can configure and build it:

     $ ./configure
     $ make && make install
    

    Note: You may need to use sudo make install if you do not normally have permission to modify the destination directory. The install locations can be adjusted by passing a --prefix argument to configure. Various other options are also supported, pass --help for more information on them.

    When complete, make install will place several programs into /usr/local/bin: rustc, the Rust compiler, and rustdoc, the API-documentation tool. system.

  3. Read the tutorial.

  4. Enjoy!

Notes

Since the Rust compiler is written in Rust, it must be built by a precompiled "snapshot" version of itself (made in an earlier state of development). As such, source builds require a connection to the Internet, to fetch snapshots, and an OS that can execute the available snapshot binaries.

Snapshot binaries are currently built and tested on several platforms:

  • Windows (7, 8, Server 2008 R2), x86 only
  • Linux (2.6.18 or later, various distributions), x86 and x86-64
  • OSX 10.7 (Lion) or greater, x86 and x86-64

You may find that other platforms work, but these are our officially supported build environments that are most likely to work.

Rust currently needs about 1.5 GiB of RAM to build without swapping; if it hits swap, it will take a very long time to build.

There is a lot more documentation in the wiki.

License

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.

See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.