5 ms·

> and also gets around C-like compilation speeds Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, s

> and also gets around C-like compilation speeds Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, so why would be expect it to have C-like speeds? Should we not also expect C to have compile speed improvements in that period, which might leave them relatively unchanged with respect to each other? It feels sort of like you're comparing a Mercedes sedan and Land Rover. Both very capably vehicles, but targeted to excel in slightly different circumstances, and when people suggest a Land Rover for rougher terrain, you're noting that when they can provide the same acceleration and gas mileage as the sedan then you'll be interested, which is both unlikely to happen and missing the point, since an off-road vehicle can do things a sedan just can't. Preferring one over the other is fine, expecting one to be superior to the other in every way is a tall order.

pjmlp 7y ago
That keeps getting brought up as reason for Rust compiler slowness, e.g. complex language requires long compile times. So then lets pick D, Delphi, .NET Native, Eiffel, Ada as examples of toolchains from complex languages that compile faster than rustc is currently capable of.
- pcwalton 7y ago
  None of which do anywhere near the level of optimization that LLVM does. They also don't do H-M type inference or borrow checking.
  - pjmlp 7y ago
    So you have measured ldc, F# .NET Native, Delphi LLVM backend, Eiffel compilation via clang?
    - pcwalton 7y ago
      I don't understand what your point is. I think you're trying to imply something like "rustc is fundamentally misdesigned and it would be easy to make huge performance improvements", but there really is not much low-hanging fruit left in rustc. The fact is that H-M type inference, borrow checking, and optimization take time. There is no magic bullet that other languages do to compile quickly that Rust does not, other than not having Rust's features or not doing optimization. There's even an entirely separate compiler implementation now, mrustc, which as far as I know is not significantly faster than rustc. There was a time when rustc could be called a relatively slow compiler for what it does, but not anymore. It's actually a reasonably fast compiler now. I expect small wins to continue in the future, but the only remaining foreseeable large win is Cranelift.
      - steveklabnik 7y ago
        I agree with your overall point, but > but the only remaining foreseeable large win is Cranelift. I'm not so sure about that, given the huge work going on to make rustc truly incremental.
        pcwalton 7y ago
        And incremental compilation is more than virtually all the listed compilers can do. I think the issue is more that not many people are using those languages in anger (except for Delphi I suppose, but Object Pascal is a comparatively simple language with no H-M inference that also does very little optimization). People don't hit the limitations.
      - pjmlp 7y ago
        I didn't say it is easy, just that there is still room for improvement. So here go my couch coach ideas. You already mentioned one possible improvement, I don't need to compile with all optimizations turned on on debug builds. Secondly, combine JIT for development with AOT compilation for release deployment, e.g. Eiffel / .NET Native. Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch. Combine that with an incremental compiler/linker, like Visual C++ does, where the team use Unreal, CryEngine, Windows, Office and other similar sized projects to measure build improvements.
        steveklabnik 7y ago
        > Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch. This already exists and is easy to use: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
        pjmlp 7y ago
        Thanks for the heads up.
        7y ago
  - Crinus 7y ago
    FWIW i do not care that much about having LLVM's optimizations. As long as there are a few decent optimizations to do most of the stupid stuff i'm fine - i can do the rest myself whenever (and if) needed. It is only a very tiny part of the codebase that would need heavy optimizations anyway, yet having to pay (in terms of compilation time) for that for the entire codebase is an absurdity that we just seem to got used to.
- kbenson 7y ago
  > complex language requires long compile times. My point is not so much that the language is complex, but that the compiler does a lot more stuff along the lines of correctness checking. If you take a C or C++ compiler and add in the equivalent level of checks that Rust is doing, can we expect it to be faster than the Rust compiler? Are any of the other examples you're putting forth doing things of the same complexity? I know many of them have their own ways of providing assurances, but I know some of them are not compile-time (or at least not more than inserting instructions for run-time checks). You would know better than me, since you've expressed previously that you have experience with many of those, at least at a cursory level. Can you comment on what they're doing at a compile time level that's approaching or surpassing the complexity of the borrow checking in Rust?
  - pjmlp 7y ago
    Regarding C++ compilation, here is the latest blog entries regarding Visual C++ compilation speedups, https://devblogs.microsoft.com/cppblog/improved-linker-fundamentals-in-visual-studio-2019/ https://devblogs.microsoft.com/cppblog/improved-linker-funda... https://devblogs.microsoft.com/cppblog/msvc-backend-updates-in-visual-studio-2019-version-16-2/ https://devblogs.microsoft.com/cppblog/msvc-backend-updates-... Another ways of improving compilation times: D has fast compiler as reference implementation, leaving the hard work for gcc and llvm backends. Eiffel uses a JIT for development, with AOT compilation via the C or C++ system compiler for production releases. .NET Native, which now also supports F# (so H-N comes into play) takes advantage of MSIL, the development builds are a bit lightweight in optimizations and only the deployment via the store does the heavy crunching of optimizations, based on Visual C++ backend.
Crinus 7y ago
> Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, so why would be expect it to have C-like speeds? I do not expect it, i'd just want it to be fast for me to want to use it. I mean, i do not really care why it is slow (outside of curiosity, but not as an for accepting it), i care that it is slow.

pjmlp 7y ago

That keeps getting brought up as reason for Rust compiler slowness, e.g. complex language requires long compile times. So then lets pick D, Delphi, .NET Native, Eiffel, Ada as examples of toolchains from complex languages that compile faster than rustc is currently capable of.

pcwalton 7y ago
None of which do anywhere near the level of optimization that LLVM does. They also don't do H-M type inference or borrow checking.
- pjmlp 7y ago
  So you have measured ldc, F# .NET Native, Delphi LLVM backend, Eiffel compilation via clang?
  - pcwalton 7y ago
    I don't understand what your point is. I think you're trying to imply something like "rustc is fundamentally misdesigned and it would be easy to make huge performance improvements", but there really is not much low-hanging fruit left in rustc. The fact is that H-M type inference, borrow checking, and optimization take time. There is no magic bullet that other languages do to compile quickly that Rust does not, other than not having Rust's features or not doing optimization. There's even an entirely separate compiler implementation now, mrustc, which as far as I know is not significantly faster than rustc. There was a time when rustc could be called a relatively slow compiler for what it does, but not anymore. It's actually a reasonably fast compiler now. I expect small wins to continue in the future, but the only remaining foreseeable large win is Cranelift.
    - steveklabnik 7y ago
      I agree with your overall point, but > but the only remaining foreseeable large win is Cranelift. I'm not so sure about that, given the huge work going on to make rustc truly incremental.
      - pcwalton 7y ago
        And incremental compilation is more than virtually all the listed compilers can do. I think the issue is more that not many people are using those languages in anger (except for Delphi I suppose, but Object Pascal is a comparatively simple language with no H-M inference that also does very little optimization). People don't hit the limitations.
    - pjmlp 7y ago
      I didn't say it is easy, just that there is still room for improvement. So here go my couch coach ideas. You already mentioned one possible improvement, I don't need to compile with all optimizations turned on on debug builds. Secondly, combine JIT for development with AOT compilation for release deployment, e.g. Eiffel / .NET Native. Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch. Combine that with an incremental compiler/linker, like Visual C++ does, where the team use Unreal, CryEngine, Windows, Office and other similar sized projects to measure build improvements.
      - steveklabnik 7y ago
        > Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch. This already exists and is easy to use: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
        pjmlp 7y ago
        Thanks for the heads up.
      - 7y ago
- Crinus 7y ago
  FWIW i do not care that much about having LLVM's optimizations. As long as there are a few decent optimizations to do most of the stupid stuff i'm fine - i can do the rest myself whenever (and if) needed. It is only a very tiny part of the codebase that would need heavy optimizations anyway, yet having to pay (in terms of compilation time) for that for the entire codebase is an absurdity that we just seem to got used to.
kbenson 7y ago
> complex language requires long compile times. My point is not so much that the language is complex, but that the compiler does a lot more stuff along the lines of correctness checking. If you take a C or C++ compiler and add in the equivalent level of checks that Rust is doing, can we expect it to be faster than the Rust compiler? Are any of the other examples you're putting forth doing things of the same complexity? I know many of them have their own ways of providing assurances, but I know some of them are not compile-time (or at least not more than inserting instructions for run-time checks). You would know better than me, since you've expressed previously that you have experience with many of those, at least at a cursory level. Can you comment on what they're doing at a compile time level that's approaching or surpassing the complexity of the borrow checking in Rust?
- pjmlp 7y ago
  Regarding C++ compilation, here is the latest blog entries regarding Visual C++ compilation speedups, https://devblogs.microsoft.com/cppblog/improved-linker-fundamentals-in-visual-studio-2019/ https://devblogs.microsoft.com/cppblog/improved-linker-funda... https://devblogs.microsoft.com/cppblog/msvc-backend-updates-in-visual-studio-2019-version-16-2/ https://devblogs.microsoft.com/cppblog/msvc-backend-updates-... Another ways of improving compilation times: D has fast compiler as reference implementation, leaving the hard work for gcc and llvm backends. Eiffel uses a JIT for development, with AOT compilation via the C or C++ system compiler for production releases. .NET Native, which now also supports F# (so H-N comes into play) takes advantage of MSIL, the development builds are a bit lightweight in optimizations and only the deployment via the store does the heavy crunching of optimizations, based on Visual C++ backend.

Crinus 7y ago

> Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, so why would be expect it to have C-like speeds? I do not expect it, i'd just want it to be fast for me to want to use it. I mean, i do not really care why it is slow (outside of curiosity, but not as an for accepting it), i care that it is slow.