6 ms·

> 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 unwindin

> 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
    > The claim is that LLVM is slow, so it's not Rust's fault. I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem. I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR. That’s one that does get talked about a lot. I don’t think we’re really gonna make any progress here so I’ll leave it at that.
    - civility 8y ago

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
  > The claim is that LLVM is slow, so it's not Rust's fault. I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem. I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR. That’s one that does get talked about a lot. I don’t think we’re really gonna make any progress here so I’ll leave it at that.
  - civility 8y ago