7 ms·

Dude wants a compiler and wants to go fast. And he picks rust? Guys been hanging out way too long on hackernews.

Annatar 8y ago
Could not have put it better myself. If he wants fast, short of hand writing in assembler, CUDA Fortran is the way to go. Too much exposure to "Hacker" "News".
tomrod 8y ago
Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.
- 0815test 8y ago
  The Rust compiler is well known for having rather less-than-stellar performance, and this can definitely impact larger projects. (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. It's not exactly an easy issue to address, given that LLVM itself is rather old and clunky code; written in C++ for maximum portability, not so much performance.)
  - AsyncAwait 8y ago
    > The Rust compiler is well known for having rather less-than-stellar performance. You can do 'cargo check' to do the analysis part without actually compiling a binary, it's super fast and excellent for development.
  - civility 8y ago
    > 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.)

Could not have put it better myself. If he wants fast, short of hand writing in assembler, CUDA Fortran is the way to go. Too much exposure to "Hacker" "News".

tomrod 8y ago

Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.

0815test 8y ago
The Rust compiler is well known for having rather less-than-stellar performance, and this can definitely impact larger projects. (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. It's not exactly an easy issue to address, given that LLVM itself is rather old and clunky code; written in C++ for maximum portability, not so much performance.)
- AsyncAwait 8y ago
  > The Rust compiler is well known for having rather less-than-stellar performance. You can do 'cargo check' to do the analysis part without actually compiling a binary, it's super fast and excellent for development.
- civility 8y ago
  > 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.)