5 ms·

Does this article account for the fact that a rustc compilation does more things than simple C++ default compilation, where you need to run address sanitizers e

by oslac 4y ago

Does this article account for the fact that a rustc compilation does more things than simple C++ default compilation, where you need to run address sanitizers etc. to do the same as rustc?

strager 4y ago
No. If I was going to run sanitizers with the C++ code, for a fair comparison, I would also run the Rust code with Miri. (C++ sanitizers check unsafe code, but without Miri, rustc mostly checks only safe code.)
- vegerot 4y ago
  What about the other way around? Trying to cripple rustc until its features are closer to clang's? For example, removing some of the sanitizers or borrow checker in rustc?
  - strager 4y ago
    That's a great idea! Unfortunately, I think there's no way to disable rustc's borrow checking or other safety features.
- insanitybit 4y ago
  Just fwiw you can run rust code with sanitizers, no need for miri, which works differently.
  - strager 4y ago
    Oh, I did not know this.
jupp0r 4y ago
Compilation doesn't necessarily need strict checks, it's really just translating source code into machine code. It happens to be the case that we mostly do both using the same tools because compilers need to have a good understanding of type systems to do their job well, but it's not a strict requirement. A great counter example is esbuild, which will compile TypeScript but not perform actual type checks for performance reasons. This is possible because TypeScript types have no representation at runtime. and are really only a development tool.
insanitybit 4y ago
That doesn't seem relevant. The article isn't asking "is C++ better than rust?" or trying to make qualitative judgments on overall "worth" - it's an exploration of one area, an apples to apples (as close as possible, of course) comparison of compilation speed given a set of optimizations and constraints. Rust may do more analysis, c++ may have other tooling, but that's not relevant - the speed is the speed. Sanitizers should primarily impact runtime performance anyways, but that's moot.
- strager 4y ago
  > Sanitizers should primarily impact runtime performance anyways, but that's moot. In my experience, ASAN has a huge negative impact on build times for C++ code (Clang and GCC).
  - insanitybit 4y ago
    I guess that makes sense since they have to inject an instrumentation pass.
fooker 4y ago
That’s a language design issue, by choosing your language you choose much you want the compiler to do. So it doesn’t make sense to force that choice for the sake of comparison. Similarly, Swift code is slow to compile for because it has a weird type system.
menaerus 4y ago
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.
strager 4y ago
The article does not account for this. I wanted the fastest build-test cycle. It sounds unfair to artificially slow down C++ compilation just because Rust has undisablable checks. EDIT: Oops, I realized I already replied two hours ago.

by oslac 4y ago

Does this article account for the fact that a rustc compilation does more things than simple C++ default compilation, where you need to run address sanitizers etc. to do the same as rustc?

strager 4y ago

No. If I was going to run sanitizers with the C++ code, for a fair comparison, I would also run the Rust code with Miri. (C++ sanitizers check unsafe code, but without Miri, rustc mostly checks only safe code.)

vegerot 4y ago
What about the other way around? Trying to cripple rustc until its features are closer to clang's? For example, removing some of the sanitizers or borrow checker in rustc?
- strager 4y ago
  That's a great idea! Unfortunately, I think there's no way to disable rustc's borrow checking or other safety features.
insanitybit 4y ago
Just fwiw you can run rust code with sanitizers, no need for miri, which works differently.
- strager 4y ago
  Oh, I did not know this.

jupp0r 4y ago

Compilation doesn't necessarily need strict checks, it's really just translating source code into machine code. It happens to be the case that we mostly do both using the same tools because compilers need to have a good understanding of type systems to do their job well, but it's not a strict requirement. A great counter example is esbuild, which will compile TypeScript but not perform actual type checks for performance reasons. This is possible because TypeScript types have no representation at runtime. and are really only a development tool.

insanitybit 4y ago

That doesn't seem relevant. The article isn't asking "is C++ better than rust?" or trying to make qualitative judgments on overall "worth" - it's an exploration of one area, an apples to apples (as close as possible, of course) comparison of compilation speed given a set of optimizations and constraints. Rust may do more analysis, c++ may have other tooling, but that's not relevant - the speed is the speed. Sanitizers should primarily impact runtime performance anyways, but that's moot.

strager 4y ago
> Sanitizers should primarily impact runtime performance anyways, but that's moot. In my experience, ASAN has a huge negative impact on build times for C++ code (Clang and GCC).
- insanitybit 4y ago
  I guess that makes sense since they have to inject an instrumentation pass.

fooker 4y ago

That’s a language design issue, by choosing your language you choose much you want the compiler to do. So it doesn’t make sense to force that choice for the sake of comparison. Similarly, Swift code is slow to compile for because it has a weird type system.

menaerus 4y ago

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.

strager 4y ago

The article does not account for this. I wanted the fastest build-test cycle. It sounds unfair to artificially slow down C++ compilation just because Rust has undisablable checks. EDIT: Oops, I realized I already replied two hours ago.