4 ms·

And quite the reason why I think this was a poor choice of rust design because not being able to opt-out from static analysis, e.g. borrow checker, makes me hav

And quite the reason why I think this was a poor choice of rust design because not being able to opt-out from static analysis, e.g. borrow checker, makes me having to pay the price for it every time even when I don't want to. This as a result has unfortunate consequences on iteration times, which C++ has been infamously known of but in this respect it plays better imo then rust.

zozbot234 4y ago
Rust borrow checking is quick, as shown by cargo check. The problem with Rust compiles is (1) proc macros, when they are used and (2) the sheer amount of monomorphized generic code that rustc outputs for LLVM to deal with. Monomorphized generics should always be written to hand off substantive work to a single function that can span multiple instantiations whenever possible, but this is not done to the fullest extent in current Rust. (Partly because Rust const generics are still at the MVP stage, so it's not possible to, e.g. write a generic function that depends on known features of a type, such as alignment or size.)
- vegerot 4y ago
  No need to speculate These timings are all in the paper! Check the “Cranelift backend” section
- menaerus 4y ago
  > Rust borrow checking is quick, as shown by cargo check. Looks like monomorphization part is not caught during cargo check according to https://github.com/rust-lang/rust/issues/49292 https://github.com/rust-lang/rust/issues/49292 Reporter of the bug says: > All of those happens somewhere inside librustc_mir, most of them being monomorphization. This corresponds to translation item collection pass, which takes nontrivial amount of time. Which essentially means that cargo check is not doing all the checks that cargo build will do, so the comparison seems to be a bit off, at least for the time being. And consequently this inconsistency can easily lead to the hypothesis of LLVM backend being the bottleneck. I guess the only reasonable way to know for sure where are the biggest bottlenecks in build times is to have something similar to clang's -ftime-trace but I couldn't find anything similar existing in Rust. From what I understand, monomorphization and rust macros are essentially C++ templates in a nutshell, and probably less than, yet C++ is compiled much faster. Given that both clang and rust share the same LLVM backend, this seems like an indication to me that the bottleneck is rather in the frontend and not in the backend. It also could be that Rust frontend pipeline is not quite optimized yet so that it puts more pressure to LLVM backend than what the clang does but seems like we can't really know that for sure.
tumdum_ 4y ago
Almost always the cost of borrow checker is trivial compared to code gen (and sometimes instantiation of generics). You can see that easily by comparing time of `cargo check` and `cargo build`.
- vegerot 4y ago
  The specific time borrow check takes is in the article. Check out the section on “ Cranelift backend”
  - strager 4y ago
    Note: I wouldn't draw any conclusions from the -Zself-profile data in the article. It looks at just one rustc invocation, and is one sample.

zozbot234 4y ago

Rust borrow checking is quick, as shown by cargo check. The problem with Rust compiles is (1) proc macros, when they are used and (2) the sheer amount of monomorphized generic code that rustc outputs for LLVM to deal with. Monomorphized generics should always be written to hand off substantive work to a single function that can span multiple instantiations whenever possible, but this is not done to the fullest extent in current Rust. (Partly because Rust const generics are still at the MVP stage, so it's not possible to, e.g. write a generic function that depends on known features of a type, such as alignment or size.)

vegerot 4y ago
No need to speculate These timings are all in the paper! Check the “Cranelift backend” section
menaerus 4y ago
> Rust borrow checking is quick, as shown by cargo check. Looks like monomorphization part is not caught during cargo check according to https://github.com/rust-lang/rust/issues/49292 https://github.com/rust-lang/rust/issues/49292 Reporter of the bug says: > All of those happens somewhere inside librustc_mir, most of them being monomorphization. This corresponds to translation item collection pass, which takes nontrivial amount of time. Which essentially means that cargo check is not doing all the checks that cargo build will do, so the comparison seems to be a bit off, at least for the time being. And consequently this inconsistency can easily lead to the hypothesis of LLVM backend being the bottleneck. I guess the only reasonable way to know for sure where are the biggest bottlenecks in build times is to have something similar to clang's -ftime-trace but I couldn't find anything similar existing in Rust. From what I understand, monomorphization and rust macros are essentially C++ templates in a nutshell, and probably less than, yet C++ is compiled much faster. Given that both clang and rust share the same LLVM backend, this seems like an indication to me that the bottleneck is rather in the frontend and not in the backend. It also could be that Rust frontend pipeline is not quite optimized yet so that it puts more pressure to LLVM backend than what the clang does but seems like we can't really know that for sure.

tumdum_ 4y ago

Almost always the cost of borrow checker is trivial compared to code gen (and sometimes instantiation of generics). You can see that easily by comparing time of `cargo check` and `cargo build`.

vegerot 4y ago
The specific time borrow check takes is in the article. Check out the section on “ Cranelift backend”
- strager 4y ago
  Note: I wouldn't draw any conclusions from the -Zself-profile data in the article. It looks at just one rustc invocation, and is one sample.