7 ms·

> Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation.

> Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation. Considering clang generates LLVM IR and compiles much more quickly than Rust, this argument doesn't hold. The Rust compiler generates IR which chokes LLVM and makes it slow, but they didn't have to do that.

steveklabnik 8y ago
Yes and no; we can reduce the amount of it, but since we have different features, we will pretty much inherently generate code that skips FastISel. For example, “match” generates IR that’s not part of it. (See here for more: https://internals.rust-lang.org/t/why-cant-rust-use-llvm-fastisel/2708 https://internals.rust-lang.org/t/why-cant-rust-use-llvm-fas...) It’s a huge problem with a number of different causes.
- civility 8y ago
  > Yes and no; Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.
  - Tomte 8y ago
    Turing-completeness is – as always – a red herring. Sure, I can technically use Assembler to write a modern Windows program, but that's no argument against high-level languages.
    - civility 8y ago
      Yes, forgive me for using logic. I should stick to writing snarky comments like yours... Rust is a compiler. It needs to make machine language somehow. No one suggested writing assembly or machine language directly, but at least if they did, then they wouldn't be able to play a shell game and point their fingers at everything but the actual problem.
  - steveklabnik 8y ago
    I think you mean well with this comment, but you're thinking about it incorrectly. Imagine that it's possible to implement these features in the FastISel subset; okay, we do that. Now, we're generating way more code. So we're back to square one. Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation speed, not computational equivalence. We find tons of bugs in LLVM due to using certain features (like noalias) that are used a lot by Rust and very, very little by current C or C++ codebases. That shouldn't be particularly surprising. Nor should it be surprising that LLVM is mostly optimized for making C and C++ compilation times fast, and not necessarily other languages. Again, as I said, it's a complex, multi-faceted problem. You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works. (And, note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly." So, the thing I'm talking about is a thing that would help debug build times, but not production build times. I'm not claiming that this one specific thing is the root cause of poor compile times, in fact, I'm claiming the opposite: there are a number of different things that all come together to lead to compile times being not as fast as we'd like.)
    - civility 8y ago
      What feature of Rust requires elaborate features or massive amounts of code? C++ has stack unwinding, you can implemented dynamic dispatch in C with function pointers, and Rust's match isn't that much above a switch statement. Both C and C++ on top of LLVM compile much more quickly than Rust.
    - civility 8y ago
      You added to your comment while I was replying, so adding to what I said in the sibling reply: > Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more. > You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works. Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler. > note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly." You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.

steveklabnik 8y ago

Yes and no; we can reduce the amount of it, but since we have different features, we will pretty much inherently generate code that skips FastISel. For example, “match” generates IR that’s not part of it. (See here for more: https://internals.rust-lang.org/t/why-cant-rust-use-llvm-fastisel/2708 https://internals.rust-lang.org/t/why-cant-rust-use-llvm-fas...) It’s a huge problem with a number of different causes.

civility 8y ago
> Yes and no; Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.
- Tomte 8y ago
  Turing-completeness is – as always – a red herring. Sure, I can technically use Assembler to write a modern Windows program, but that's no argument against high-level languages.
  - civility 8y ago
    Yes, forgive me for using logic. I should stick to writing snarky comments like yours... Rust is a compiler. It needs to make machine language somehow. No one suggested writing assembly or machine language directly, but at least if they did, then they wouldn't be able to play a shell game and point their fingers at everything but the actual problem.
- steveklabnik 8y ago
  I think you mean well with this comment, but you're thinking about it incorrectly. Imagine that it's possible to implement these features in the FastISel subset; okay, we do that. Now, we're generating way more code. So we're back to square one. Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation speed, not computational equivalence. We find tons of bugs in LLVM due to using certain features (like noalias) that are used a lot by Rust and very, very little by current C or C++ codebases. That shouldn't be particularly surprising. Nor should it be surprising that LLVM is mostly optimized for making C and C++ compilation times fast, and not necessarily other languages. Again, as I said, it's a complex, multi-faceted problem. You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works. (And, note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly." So, the thing I'm talking about is a thing that would help debug build times, but not production build times. I'm not claiming that this one specific thing is the root cause of poor compile times, in fact, I'm claiming the opposite: there are a number of different things that all come together to lead to compile times being not as fast as we'd like.)
  - civility 8y ago
    What feature of Rust requires elaborate features or massive amounts of code? C++ has stack unwinding, you can implemented dynamic dispatch in C with function pointers, and Rust's match isn't that much above a switch statement. Both C and C++ on top of LLVM compile much more quickly than Rust.
  - civility 8y ago
    You added to your comment while I was replying, so adding to what I said in the sibling reply: > Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more. > You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works. Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler. > note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly." You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.