9 ms·

LLVM 13's new pass manager improves Rust's compile times by up to 20%

61 points by paavohtl 5y ago

j-pb 5y ago
Even though this is awesome as it affects everything using the LLVM toolchain, I fear that for Rust, percentages won't suffice. Rust needs multi X speedups. Rusts zero cost abstractions aren't free at all, you pay with compile time, and they ain't cheap.
- steveklabnik 5y ago
  Percentages turn into multiple X-es over time, as they build on each other. The compiler has gotten multiple X-es faster than it was at 1.0, via repeated and persistent work on those small percentage patches.
  - j-pb 5y ago
    There is a fundamental limit to that though, based on how complex rust is in a multitude of domains. From macros to types, all that stacked complexity makes amdahls law eat you alive. And it has real world implications too. Documentation could be vastly better if it could reference traits across package boundaries. With a "slow" compiler that is simply not feasible, the act of finding the relevant packages is NP hard in itself and multiplied with the compile time.
    - paavohtl 5y ago
      > Documentation could be vastly better if it could reference traits across package boundaries Could you clarify what you mean by this? As far as I know the vast, vast majority of rustc's compile time is spent on code generation (hence the massive speedup from an LLVM update), and everything else is relatively well optimized.
      - j-pb 5y ago
        When you push a package to crates.io, docs.rs will do a static analysis of this package and its dependencies and try its best to create meaningful links between the traits and implementing types. The issue is that it is quite common to have trait definitions in one create being used by other ones. Often this is even done when a single library gets too large e.g. tokio, one incentive for splitting being compile time. However since analysis happens upwards the dependency tree, nodes further up the chain won't know what's below them and can't link to them. You'd essentially have to do whole creates.io analysis, and while in theory that's feasible with static analysis, rusts type system is so powerful that you have to run a lot of the compiler to get meaningful "static" information, and thus would need a faster compiler/type checker. (Ranty tangent ;) : I'm not sure if static analysis is even feasible with rusts massive complexity, and implementation defined behaviours. I mean nobody actually _knows_ if rust is save, it's just generally assumed. The closest thing to a formal proof that I know of is Oxide (https://arxiv.org/abs/1903.00982 https://arxiv.org/abs/1903.00982). The rust "commitee" tends to defer so many descisions into the future as to not accidentally paint themselves into a corner, that the spec is just the code and a bunch of thoughts in heads, RFCs, and github issues. Hoare comes to mind: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.) So the "classes implementing this interface" which exists in the Java world, and which is really useful for exploring an API doesn't really exist for crates (at least not automatically). It creates these Trait islands, where you can navigate to, but not away from.
        paavohtl 5y ago
        Do you know that the reason for this is that the compiler is too slow, or are you making an assumption? I agree that this would be a good feature to have in docs.rs, though it could potentially make the docs very messy to read if there was no way to choose which crates to show together. I know that Rustdoc can do this; see SWC's docs for example: https://rustdoc.swc.rs/swc_ecma_visit/trait.Visit.html#implementors https://rustdoc.swc.rs/swc_ecma_visit/trait.Visit.html#imple...
- pjmlp 5y ago
  That is not what Bjarne Stroustrup means with zero cost abstractions.
  - j-pb 5y ago
    I'm aware that it's zero-runtime-cost-abstractions, but that's not what sticks with non system devs when they read rusts "marketing material" (blog posts, talks, e.t.c.)
    - pjmlp 5y ago
      Fair enough. In regards to your point, using other backends other than LLVM and cargo having full support for binary libraries would solve a big part of the compilation time story. In spite of its fame, C++ builds can be made relatively fast when using binary libraries, and even on its baby state, one can already notice some difference with modules workloads in Visual C++. So I am still hopeful that Rust will improve its compilation story.
      - zozbot234 5y ago
        Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. Meanwhile C++ is stuck with 'ABI stability' practices that prevent all sorts of otherwise desirable changes in C++ library code, because they would introduce breaks in binary compatibility.
        paavohtl 5y ago
        > Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. I've never seen this in the wild and to be honest, it seems massively inconvenient to write a library, create a C-compatible interface for it (meaning you lose out on most benefits of Rust's type system), and then write a wrapper for said C-like API to regain type/memory safety and abstraction power. The killer is that you lose the ability to use traits in the interface between, which idiomatic Rust heavily relies upon.
- mountainriver 5y ago
  Exactly, I always bring this up with the rust community, zero cost abstractions feels more like a sales pitch

61 points by paavohtl 5y ago

j-pb 5y ago

Even though this is awesome as it affects everything using the LLVM toolchain, I fear that for Rust, percentages won't suffice. Rust needs multi X speedups. Rusts zero cost abstractions aren't free at all, you pay with compile time, and they ain't cheap.

steveklabnik 5y ago
Percentages turn into multiple X-es over time, as they build on each other. The compiler has gotten multiple X-es faster than it was at 1.0, via repeated and persistent work on those small percentage patches.
- j-pb 5y ago
  There is a fundamental limit to that though, based on how complex rust is in a multitude of domains. From macros to types, all that stacked complexity makes amdahls law eat you alive. And it has real world implications too. Documentation could be vastly better if it could reference traits across package boundaries. With a "slow" compiler that is simply not feasible, the act of finding the relevant packages is NP hard in itself and multiplied with the compile time.
  - paavohtl 5y ago
    > Documentation could be vastly better if it could reference traits across package boundaries Could you clarify what you mean by this? As far as I know the vast, vast majority of rustc's compile time is spent on code generation (hence the massive speedup from an LLVM update), and everything else is relatively well optimized.
    - j-pb 5y ago
      When you push a package to crates.io, docs.rs will do a static analysis of this package and its dependencies and try its best to create meaningful links between the traits and implementing types. The issue is that it is quite common to have trait definitions in one create being used by other ones. Often this is even done when a single library gets too large e.g. tokio, one incentive for splitting being compile time. However since analysis happens upwards the dependency tree, nodes further up the chain won't know what's below them and can't link to them. You'd essentially have to do whole creates.io analysis, and while in theory that's feasible with static analysis, rusts type system is so powerful that you have to run a lot of the compiler to get meaningful "static" information, and thus would need a faster compiler/type checker. (Ranty tangent ;) : I'm not sure if static analysis is even feasible with rusts massive complexity, and implementation defined behaviours. I mean nobody actually _knows_ if rust is save, it's just generally assumed. The closest thing to a formal proof that I know of is Oxide (https://arxiv.org/abs/1903.00982 https://arxiv.org/abs/1903.00982). The rust "commitee" tends to defer so many descisions into the future as to not accidentally paint themselves into a corner, that the spec is just the code and a bunch of thoughts in heads, RFCs, and github issues. Hoare comes to mind: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.) So the "classes implementing this interface" which exists in the Java world, and which is really useful for exploring an API doesn't really exist for crates (at least not automatically). It creates these Trait islands, where you can navigate to, but not away from.
      - paavohtl 5y ago
        Do you know that the reason for this is that the compiler is too slow, or are you making an assumption? I agree that this would be a good feature to have in docs.rs, though it could potentially make the docs very messy to read if there was no way to choose which crates to show together. I know that Rustdoc can do this; see SWC's docs for example: https://rustdoc.swc.rs/swc_ecma_visit/trait.Visit.html#implementors https://rustdoc.swc.rs/swc_ecma_visit/trait.Visit.html#imple...
pjmlp 5y ago
That is not what Bjarne Stroustrup means with zero cost abstractions.
- j-pb 5y ago
  I'm aware that it's zero-runtime-cost-abstractions, but that's not what sticks with non system devs when they read rusts "marketing material" (blog posts, talks, e.t.c.)
  - pjmlp 5y ago
    Fair enough. In regards to your point, using other backends other than LLVM and cargo having full support for binary libraries would solve a big part of the compilation time story. In spite of its fame, C++ builds can be made relatively fast when using binary libraries, and even on its baby state, one can already notice some difference with modules workloads in Visual C++. So I am still hopeful that Rust will improve its compilation story.
    - zozbot234 5y ago
      Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. Meanwhile C++ is stuck with 'ABI stability' practices that prevent all sorts of otherwise desirable changes in C++ library code, because they would introduce breaks in binary compatibility.
      - paavohtl 5y ago
        > Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. I've never seen this in the wild and to be honest, it seems massively inconvenient to write a library, create a C-compatible interface for it (meaning you lose out on most benefits of Rust's type system), and then write a wrapper for said C-like API to regain type/memory safety and abstraction power. The killer is that you lose the ability to use traits in the interface between, which idiomatic Rust heavily relies upon.
mountainriver 5y ago
Exactly, I always bring this up with the rust community, zero cost abstractions feels more like a sales pitch