6 ms·

Performance of the generated code is always the #1 priority in both Rust and llvm, performance improvements are rarely declined, and this prioritization needs t

Performance of the generated code is always the #1 priority in both Rust and llvm, performance improvements are rarely declined, and this prioritization needs to change radically, to get a much faster compiler.

steveklabnik 6y ago
Prioritization is not that straightforward. Every open source project has different sub-groups with different goals. While we do care a ton about generated code, there is also movement by other folks to work on the compiler speed problem. It has been a lot of work to come this far, and it will be even more work to get to a better place, but that work is underway. That's not even to mention that since rustc is written in Rust, work to make generated code faster can also make the compiler faster. I'm referring to the rust-analyzer work, which is effectively an outside-in re-write of the compiler, if you squint at it right. At the end of the day, rustc is a very large codebase, and has already undergone major architectural changes, and will be undergoing even more. It is not fast to steer a large ship in a new direction, but that is what is happening. See https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=900x900 https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=... for a time I ran https://github.com/erikbern/git-of-theseus https://github.com/erikbern/git-of-theseus on the rustc codebase. Thank goodness Rust is such a good refactoring language.
- kzrdude 6y ago
  You are talking incremental improvements. Radical is needed not just using cranelift for debug builds, but something like that for all builds. Current llvm model does not work well for delivering a fast compiler (opt and non-debug)
  - steveklabnik 6y ago
    You can deliver radical improvements in an incremental fashion. The move towards a query-based architecture, and the rust-analyzer work, are both fundamental, radical improvements. If anything, the cranelift stuff is less radical. Doesn't require any architecture changes, "only" involves implementing the backend API.
    - leeoniya 6y ago
      then there's also ongoing work in rustc_codegen_cranelift, which [as of 2 weeks ago] can now compile rustc: https://github.com/bjorn3/rustc_codegen_cranelift/issues/743#issuecomment-651108168 https://github.com/bjorn3/rustc_codegen_cranelift/issues/743...
      - steveklabnik 6y ago
        Yeah to be clear, I am very excited about cranelift too!
    - kzrdude 6y ago
      Sure, that's seriously cool but I don't see how it changes the material balance so to speak... If you still want llvm to codegen the same items, we don't have any radical departure at all, just a different way to do the same thing, when we are release-compiling any particular crate, from scratch.
      - steveklabnik 6y ago
        Oh sure, if you're talking purely about a final release build, then yes. But most of the time, compiles are not final release build compiles. People don't generally complain about final release build times. They complain about the build time as they're developing.
        vlovich123 6y ago
        Final release build times are up there as build automation systems are often at capacity
        steveklabnik 6y ago
        For sure, and I don't mean to say that they don't matter. I have worked on codebases that only use release mode, for reasons, for example. I just hear less complaints about it, that's all I'm saying :)
- jbkcc 6y ago
  d
FpUser 6y ago
What is wrong having 2 versions: slower at runtime but super fast compile for debug and the other way around for production?
- necubi 6y ago
  Of course, that is the status quo for rustc (as it is for all production compilers I know of). The issues are that (1) debug builds are still slow enough to be annoying, and (2) they are sometimes _so much slower_ to execute that a debug build + test run is slower than a release build + run. A lot of work is being done to address these issues. The big projects I'm aware of are a move to a query-based compiler (which should improve incremental build times) and the new cranelift backend, which should dramatically speed up debug build times.

steveklabnik 6y ago

Prioritization is not that straightforward. Every open source project has different sub-groups with different goals. While we do care a ton about generated code, there is also movement by other folks to work on the compiler speed problem. It has been a lot of work to come this far, and it will be even more work to get to a better place, but that work is underway. That's not even to mention that since rustc is written in Rust, work to make generated code faster can also make the compiler faster. I'm referring to the rust-analyzer work, which is effectively an outside-in re-write of the compiler, if you squint at it right. At the end of the day, rustc is a very large codebase, and has already undergone major architectural changes, and will be undergoing even more. It is not fast to steer a large ship in a new direction, but that is what is happening. See https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=900x900 https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=... for a time I ran https://github.com/erikbern/git-of-theseus https://github.com/erikbern/git-of-theseus on the rustc codebase. Thank goodness Rust is such a good refactoring language.

kzrdude 6y ago
You are talking incremental improvements. Radical is needed not just using cranelift for debug builds, but something like that for all builds. Current llvm model does not work well for delivering a fast compiler (opt and non-debug)
- steveklabnik 6y ago
  You can deliver radical improvements in an incremental fashion. The move towards a query-based architecture, and the rust-analyzer work, are both fundamental, radical improvements. If anything, the cranelift stuff is less radical. Doesn't require any architecture changes, "only" involves implementing the backend API.
  - leeoniya 6y ago
    then there's also ongoing work in rustc_codegen_cranelift, which [as of 2 weeks ago] can now compile rustc: https://github.com/bjorn3/rustc_codegen_cranelift/issues/743#issuecomment-651108168 https://github.com/bjorn3/rustc_codegen_cranelift/issues/743...
    - steveklabnik 6y ago
      Yeah to be clear, I am very excited about cranelift too!
  - kzrdude 6y ago
    Sure, that's seriously cool but I don't see how it changes the material balance so to speak... If you still want llvm to codegen the same items, we don't have any radical departure at all, just a different way to do the same thing, when we are release-compiling any particular crate, from scratch.
    - steveklabnik 6y ago
      Oh sure, if you're talking purely about a final release build, then yes. But most of the time, compiles are not final release build compiles. People don't generally complain about final release build times. They complain about the build time as they're developing.
      - vlovich123 6y ago
        Final release build times are up there as build automation systems are often at capacity
        steveklabnik 6y ago
        For sure, and I don't mean to say that they don't matter. I have worked on codebases that only use release mode, for reasons, for example. I just hear less complaints about it, that's all I'm saying :)
jbkcc 6y ago
d

FpUser 6y ago

What is wrong having 2 versions: slower at runtime but super fast compile for debug and the other way around for production?

necubi 6y ago
Of course, that is the status quo for rustc (as it is for all production compilers I know of). The issues are that (1) debug builds are still slow enough to be annoying, and (2) they are sometimes _so much slower_ to execute that a debug build + test run is slower than a release build + run. A lot of work is being done to address these issues. The big projects I'm aware of are a move to a query-based compiler (which should improve incremental build times) and the new cranelift backend, which should dramatically speed up debug build times.