5 ms·

What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to

What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.

mbrubeck 11y ago
The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.) This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.
- glandium 11y ago
  It's also a "let's rebuild everything every time" problem. Hopefully, that will be fixed with support for building incrementally. (Also note that compiling a C++ file with 2000 lines can take a very long time too)
  - plq 11y ago
    You must not forget that thanks to the preprocessor, what looks like 2000 lines may in fact be around 200k lines E.g. I have a very innocent 2000-line MainWindow.cpp that weighs 244419 lines when measured with gcc -E -o - | wc -l
    - stevedonovan 11y ago
      Good point, it really is quite staggering what a C++ compiler has to digest to compile a standard "Hello, World!". Hopefully the much-anticipated module system will help here. Generally I find that avoiding Boost libraries (including std::regex) helps enormously ;)
pcwalton 11y ago
On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything. Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amount of LLVM IR we generate to speed up codegen. There have also been designs for incremental and parallel compilation that will be long-term but have potential for big improvements down the road. I think with careful work we can get down to a good edit/compile/run experience. Compilation speed probably won't ever be as good as a direct-to-assembly compiler for language with an extremely simple type system with no real IR for optimization would be, but I don't believe there's a magic bullet that will beat LLVM's compiler performance while providing excellent optimization, and for Rust's goals we need the runtime performance.
- int3 11y ago
  Is rustc able to run typechecking without doing codegen?
  - Manishearth 11y ago
    `rustc .... -Z no-trans`. kibwen is working on a mode where rustc can generate crates with just metadata, and use it for a `cargo check` mode.
- pjmlp 11y ago
  I think a big issue is that even if it takes a few more seconds, it is still a big win compared with C and C++ builds, usually measured in hours. But I guess it is a block for those used to programming languages with traditional interpreter implementations. My biggest complain when trying out Rust was the C++ build times of the bootstrapping process. As for using pre-compiled Rust, I think the compile times are pretty acceptable for 1.0.
  - tarblog 11y ago
    > C and C++ builds, usually measured in hours. Do you have a source or a story about this? I hadn't heard numbers like that before.
the_mitsuhiko 11y ago
> What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for. Compiling racer currently needs 2GB of RAM for no good reason. So I'm pretty sure there is ample room for optimizations.
the_mitsuhiko 11y ago
> What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for. Compiling racer currently needs 2GB of RAM for no good reason. So I'm pretty sure there is ample room for optimizations.

mbrubeck 11y ago

The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.) This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.

glandium 11y ago
It's also a "let's rebuild everything every time" problem. Hopefully, that will be fixed with support for building incrementally. (Also note that compiling a C++ file with 2000 lines can take a very long time too)
- plq 11y ago
  You must not forget that thanks to the preprocessor, what looks like 2000 lines may in fact be around 200k lines E.g. I have a very innocent 2000-line MainWindow.cpp that weighs 244419 lines when measured with gcc -E -o - | wc -l
  - stevedonovan 11y ago
    Good point, it really is quite staggering what a C++ compiler has to digest to compile a standard "Hello, World!". Hopefully the much-anticipated module system will help here. Generally I find that avoiding Boost libraries (including std::regex) helps enormously ;)

pcwalton 11y ago

On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything. Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amount of LLVM IR we generate to speed up codegen. There have also been designs for incremental and parallel compilation that will be long-term but have potential for big improvements down the road. I think with careful work we can get down to a good edit/compile/run experience. Compilation speed probably won't ever be as good as a direct-to-assembly compiler for language with an extremely simple type system with no real IR for optimization would be, but I don't believe there's a magic bullet that will beat LLVM's compiler performance while providing excellent optimization, and for Rust's goals we need the runtime performance.

int3 11y ago
Is rustc able to run typechecking without doing codegen?
- Manishearth 11y ago
  `rustc .... -Z no-trans`. kibwen is working on a mode where rustc can generate crates with just metadata, and use it for a `cargo check` mode.
pjmlp 11y ago
I think a big issue is that even if it takes a few more seconds, it is still a big win compared with C and C++ builds, usually measured in hours. But I guess it is a block for those used to programming languages with traditional interpreter implementations. My biggest complain when trying out Rust was the C++ build times of the bootstrapping process. As for using pre-compiled Rust, I think the compile times are pretty acceptable for 1.0.
- tarblog 11y ago
  > C and C++ builds, usually measured in hours. Do you have a source or a story about this? I hadn't heard numbers like that before.

the_mitsuhiko 11y ago

> What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for. Compiling racer currently needs 2GB of RAM for no good reason. So I'm pretty sure there is ample room for optimizations.

the_mitsuhiko 11y ago