10 ms·

The Rust compiler is still getting faster

324 points by nnethercote 7y ago

sddfd 7y ago
This is great! Many dev hours are spend waiting for the compiler, every second counts! The second order effects are even worse. After a minute, the programmer will start thinking about other things, running flow. If compiles regularly take 5min, devs will leave their desks (and honestly, who can blame them for it).
- ChrisSD 7y ago
  Incremental compiling has helped a lot here. Even if the first compilation takes awhile, the next one will be much swifter. It's especially useful when only making minor changes to the code (which is pretty common).
- fluffything 7y ago
  I just use `cargo watch -x test -d 5` to run all my tests after I pause modifying code for 5 seconds. My editor (emacs) uses `cargo watch -x check -d 0.5` to run `cargo check` (which is blazing fast for incremental edits) to type check all the code and show "red squiggles" with the error messages inline. So my interactive workflow with Rust is only edit-"type check"-edit-"type check" where "type check" takes often less than a second. Asynchronously in the background, the whole test suite (or the part that makes sense for what I'm doing) is always being run. So if a test actually fails to run, I discover that a little bit later. I don't know any language for which running all tests happens instantaneously. With Rust, if anything, I write less tests because there are many things I don't need to check (e.g. what happens on out-of-bounds accesses). This is the best workflow I've ever had. In C++ there was no way to only run type checking, so one always had to run the full compilation and linking stages, where linking took a long time, and you could get template instantiation errors quite late, and well, linking errors. I don't think I've ever seen a Rust linking error. They probably do happen, but in C++ they happen relatively often (at least once per week).
  - ynik 7y ago
    > In C++ there was no way to only run type checking gcc has -fsyntax-only. Despite the option name, this also includes type checking and template instantiation. AFAIK it reports all compiler errors, though it skips some warnings that are computed by the optimizer (e.g. -Wuninitialized).
    - fluffything 7y ago
      Is there an easy way to tell CMake or Makefiles to use it ? I never invoke clang or gcc directly. When using cargo, I use `cargo check` instead of `cargo build`. But in C or C++ depending on the project `make check` might not exist, or it might build all tests and run them, or do something else entirely like checking the formatting using clang-format.
      - gpderetta 7y ago
        > - CMake > - Easy Pick one. I'm sure there is though. It wouldn't be hard with make but then again I'm much more familiar with it than cmake.
        fluffything 7y ago
        So I manage to get it to work in the command line using `CXXFLAGS="$CXXFLAGS -fsyntax-check" cmake ... && make` !
        gpderetta 7y ago
        One issue with that is that is, unless there is magic handling of the flag in cmake, it might still attempt (and fail) to run the linking stages. You might need custom targets jut for this.
      - humanrebar 7y ago
        Dump a compilation database with -CMAKE_EXPORT_COMPILE_COMMANDS=1 and wire up a script to call those commands but with the syntax only flag.
- moccachino 7y ago
  Reading this reminded me that I'm only here because I was waiting for a compilation & flashing to finish. I will not tell you how many minutes ago.
- adrianmonk 7y ago
  > start thinking about other things, running flow. I've found it a helpful practice as a programmer to be intentional about this. With a little awareness, you can identify situations where it really would be best to busy-wait while something compiles. (If the wait is not all that long and switching tasks harms focus.) And with a little mental discipline and practice, you can train your mind not to wander. You don't totally blank your mind out, but you also don't let unrelated thoughts distract you. Just continue to think about the same thing you were when the compile started. Don't shift gears mentally, just ease up on the mental gas pedal. It's so easy to let anxiety or guilt about wasting 2 minutes lead you into giving up focus, which is more precious. It's a false economy, and thus doing something else with those 2 minutes is actually more of a temptation than a smart idea. (Of course, it's better if the tools are just fast! But sometimes you can't have that.)
fluffything 7y ago
The rust compiler now has features that few or none C and C++ compilers have: incremental compilation within a single translation unit, pipelined compilation, multi-threaded and lazy query-based compilation, ... Implementing each of these features have required whole program refactorings in a large-scale codebase performed by few individuals while hundreds of other developers where simultaneously evolving the software and implementing new features. Having been a C++ programmer for over 10 years, none of these refactorings would have payed off in C++ because of how time consuming it would have been to track all bugs introduced by them. Yet they do pay off in Rust because of my favourite Rust feature: the ability to refactor large-scale software without breaking anything: if a non-functional change compiles, "it works" for some definition of "works" that's much better than what most other languages give you (no memory unsafety, no data-races, no segfaults...). Very few programming languages have this feature, and no low-level programming language except for Rust has it. Software design is not an upfront-only task, and Rust let's you iterate on software design as you better understand the problem domain or the constraints and requirements change without having to rewrite things from scratch.
- nindalf 7y ago
  The rust compiler team continues to set ambitious goals. Last I checked they wanted to extract much of the compiler front end into independent crates that can be reused by the Language Server. That's a pretty daunting refactoring, but the way they're going seems like it's achievable.
  - derefr 7y ago
    The one thing I’ve always wanted from a language runtime is for the data structures used by the compiler to be exposed in the stdlib. E.g. every compiler uses control flow graphs; so why doesn’t every language give me a batteries-included digraph ADT, that has every feature you’d need to implement a control flow graph, such that the compiler’s CFG is just a stdlib digraph instance? It’d be a great boon to writing your own compilers, interpreters, JITs and static-analysis tools in said language. (One language that does some of this is Erlang, but AFAIK the stdlib data structures like digraphs, sets-of-sets, etc. aren’t actually the ones the compiler uses, but are rather there for use by static verification tools like Dialyzer. Which means that the Erlang digraph doesn’t know how to topsort itself, even though there’s a module in the Erlang compiler application that does topsort on digraphs. Still feels like being a second-class citizen relative to the runtime’s favoured compiler.)
howenterprisey 7y ago
Does LLVM still take up much of the overall time spent by the Rust compiler? I was thinking of getting involved over there as the most effective way to make speed-ups happen.
- rehemiau 7y ago
  Probably yes, the LLVM linker is really slow
  - mtzet 7y ago
    Really? I seem to recall lld being comparable to cp in speed, with the caveat that compacting debug strings can take a long time (if you enable that option). Reference: https://fosdem.org/2019/schedule/event/llvm_lld/ https://fosdem.org/2019/schedule/event/llvm_lld/
    - pornel 7y ago
      Depends on the platform and the build type. For example, on macOS in debug builds, the compiler and linker are reasonably fast, but then 2/3rds of the compilation time is spent in "dsymutil", presumably chewing through megabytes of the debug info.
  - GrayShade 7y ago
    Rust is only using LLD on ARM targets.
    - est31 7y ago
      It's used on wasm as well.
- nindalf 7y ago
  I remember reading that it does, but because the LLVM IR generated by rustc is verbose. If less IR was generated, LLVM would have less work to do.
PunksATawnyFill 7y ago
What is Rust good for, as opposed to Swift or Kotlin?
pornel 7y ago
Faster compiler is nice, but you know what's faster? Not having to compile anything. I'm also looking forward to crates.io serving precompiled crates (https://www.ncameron.org/blog/cargo-in-2019/ https://www.ncameron.org/blog/cargo-in-2019/)
- pjmlp 7y ago
  Looking forward to it. If I would enjoy compiling everything from scratch I would be using Gentoo.
- skunkpocalypse 7y ago
  Ew, gross. Crates.io is already a security trainwreck in progress. Do we really need to add even more attack vectors? It's also solving a non-problem. I modify source code downloaded from crates.io zero times per day, so I compile each crate only once. Compile times matter for code I write myself: I modify (and therefore compile) that code dozens of times per day.
- jazoom 7y ago
  I'm a Rust noob but I think skunkopalypse was making some good points. I wish people didn't vote down his/her comment to death and actually replied to it so I could learn why he/she wasn't right.
  - est31 7y ago
    I too think that precompiling crates won't really solve the problem. If you compare the compiled artifact (rlib) of a crate with the source code, you'll quickly see that the compiled artifact is much larger than the source code. libglutin-0c732c31a1d003fb.rlib has 8.1 MB while glutin-0.22.0-alpha1.crate has 53 KB. Most people have shitty internet. And often it's nothing you can do about it because you have shitty ISPs. You can buy a computer with good CPUs and those are usually cheaper in comparison than good internet for a year, at least in many rural areas in the US. It's not just the US, some other countries have it even worse. Now of course if you have good internet and a bad CPU it's a good deal, so there should definitely be an option to use it, maybe even with autodetection. But I think cargo has too much dependency on the internet, not too little. There should be no manual input required to turn off precompiled crates downloads if it is faster to compile the crates locally.
nn3 7y ago
1. make a really slow compiler 2. slightly improve it over time 3. write blogs about it 4. win? How about releasing software with reasonable performance in the first place? This was just discussed yesterday that everyone prefers faster software.
- carlmr 7y ago
  For most software I would agree with you. Usually you have some CRUD application where people don't know how to index and use hashing. But the Rust compiler is an amazing static analyzer. Running one on C++ to get the same level of memory safety will often take hours on sizeable projects.
  - blub 7y ago
    A static analyzer which requires correct code to be rewritten in a certain way to satisfy the analyzer does not deserve to be called amazing.
    - oblio 7y ago
      Don't all static analyzers do that? Or they're just ignored, which happened in almost every large project I've ever seen.
      - carlmr 7y ago
        Exactly. C++ code has so much variability that 90% of static analyzer warnings are worthless. So people ignore them and create terrible unsafe code.
        blub 7y ago
        My comment had nothing to do with C++ or any other particular language, you're using it as a red herring to divert attention from the fact that the Rust analyzer requires changing the way you write code, making it not awesome, but ordinary. And speaking of C++, it's obvious that Rust programmers take a very adversarial stance towards C++, but you should be instead thankful that it exists, because without it many of those marketing articles would lose their meaning. "Slow compiler is now less slow, but probably still slower than those of other languages you know" doesn't quite have the same effect.
pmoriarty 7y ago
I wish compiling the Rust compiler itself was faster. It literally takes days to compile on my old laptop.
- cwp 7y ago
  It is! The article is about the performance of the compiler, not the machine code it generates.
- mitchty 7y ago
  Try on arm! You'll wish you hadn't! >.< I think I spent 3-4 days compiling rust, almost forgot I started it at the time.
- van2z 7y ago
  Wait, what language were you compiling it on?
  - zamadatix 7y ago
    Rust has been bootstrapped for a long time now.
johnklos 7y ago
Maybe they should make compiling the Rust compiler faster. Right now it takes longer and uses more CPU and memory than compiling a whole LLVM toolchain, then using that toolchain to compile a whole kernel and OS.
- steveklabnik 7y ago
  Compiling the Rust compiler also requires compiling LLVM, so by definition it will always take longer than that.

324 points by nnethercote 7y ago

This is great! Many dev hours are spend waiting for the compiler, every second counts! The second order effects are even worse. After a minute, the programmer will start thinking about other things, running flow. If compiles regularly take 5min, devs will leave their desks (and honestly, who can blame them for it).

ChrisSD 7y ago
Incremental compiling has helped a lot here. Even if the first compilation takes awhile, the next one will be much swifter. It's especially useful when only making minor changes to the code (which is pretty common).
fluffything 7y ago
I just use `cargo watch -x test -d 5` to run all my tests after I pause modifying code for 5 seconds. My editor (emacs) uses `cargo watch -x check -d 0.5` to run `cargo check` (which is blazing fast for incremental edits) to type check all the code and show "red squiggles" with the error messages inline. So my interactive workflow with Rust is only edit-"type check"-edit-"type check" where "type check" takes often less than a second. Asynchronously in the background, the whole test suite (or the part that makes sense for what I'm doing) is always being run. So if a test actually fails to run, I discover that a little bit later. I don't know any language for which running all tests happens instantaneously. With Rust, if anything, I write less tests because there are many things I don't need to check (e.g. what happens on out-of-bounds accesses). This is the best workflow I've ever had. In C++ there was no way to only run type checking, so one always had to run the full compilation and linking stages, where linking took a long time, and you could get template instantiation errors quite late, and well, linking errors. I don't think I've ever seen a Rust linking error. They probably do happen, but in C++ they happen relatively often (at least once per week).
- ynik 7y ago
  > In C++ there was no way to only run type checking gcc has -fsyntax-only. Despite the option name, this also includes type checking and template instantiation. AFAIK it reports all compiler errors, though it skips some warnings that are computed by the optimizer (e.g. -Wuninitialized).
  - fluffything 7y ago
    Is there an easy way to tell CMake or Makefiles to use it ? I never invoke clang or gcc directly. When using cargo, I use `cargo check` instead of `cargo build`. But in C or C++ depending on the project `make check` might not exist, or it might build all tests and run them, or do something else entirely like checking the formatting using clang-format.
    - gpderetta 7y ago
      > - CMake > - Easy Pick one. I'm sure there is though. It wouldn't be hard with make but then again I'm much more familiar with it than cmake.
      - fluffything 7y ago
        So I manage to get it to work in the command line using `CXXFLAGS="$CXXFLAGS -fsyntax-check" cmake ... && make` !
        gpderetta 7y ago
        One issue with that is that is, unless there is magic handling of the flag in cmake, it might still attempt (and fail) to run the linking stages. You might need custom targets jut for this.
    - humanrebar 7y ago
      Dump a compilation database with -CMAKE_EXPORT_COMPILE_COMMANDS=1 and wire up a script to call those commands but with the syntax only flag.
moccachino 7y ago
Reading this reminded me that I'm only here because I was waiting for a compilation & flashing to finish. I will not tell you how many minutes ago.
adrianmonk 7y ago
> start thinking about other things, running flow. I've found it a helpful practice as a programmer to be intentional about this. With a little awareness, you can identify situations where it really would be best to busy-wait while something compiles. (If the wait is not all that long and switching tasks harms focus.) And with a little mental discipline and practice, you can train your mind not to wander. You don't totally blank your mind out, but you also don't let unrelated thoughts distract you. Just continue to think about the same thing you were when the compile started. Don't shift gears mentally, just ease up on the mental gas pedal. It's so easy to let anxiety or guilt about wasting 2 minutes lead you into giving up focus, which is more precious. It's a false economy, and thus doing something else with those 2 minutes is actually more of a temptation than a smart idea. (Of course, it's better if the tools are just fast! But sometimes you can't have that.)

fluffything 7y ago

The rust compiler now has features that few or none C and C++ compilers have: incremental compilation within a single translation unit, pipelined compilation, multi-threaded and lazy query-based compilation, ... Implementing each of these features have required whole program refactorings in a large-scale codebase performed by few individuals while hundreds of other developers where simultaneously evolving the software and implementing new features. Having been a C++ programmer for over 10 years, none of these refactorings would have payed off in C++ because of how time consuming it would have been to track all bugs introduced by them. Yet they do pay off in Rust because of my favourite Rust feature: the ability to refactor large-scale software without breaking anything: if a non-functional change compiles, "it works" for some definition of "works" that's much better than what most other languages give you (no memory unsafety, no data-races, no segfaults...). Very few programming languages have this feature, and no low-level programming language except for Rust has it. Software design is not an upfront-only task, and Rust let's you iterate on software design as you better understand the problem domain or the constraints and requirements change without having to rewrite things from scratch.

nindalf 7y ago
The rust compiler team continues to set ambitious goals. Last I checked they wanted to extract much of the compiler front end into independent crates that can be reused by the Language Server. That's a pretty daunting refactoring, but the way they're going seems like it's achievable.
- derefr 7y ago
  The one thing I’ve always wanted from a language runtime is for the data structures used by the compiler to be exposed in the stdlib. E.g. every compiler uses control flow graphs; so why doesn’t every language give me a batteries-included digraph ADT, that has every feature you’d need to implement a control flow graph, such that the compiler’s CFG is just a stdlib digraph instance? It’d be a great boon to writing your own compilers, interpreters, JITs and static-analysis tools in said language. (One language that does some of this is Erlang, but AFAIK the stdlib data structures like digraphs, sets-of-sets, etc. aren’t actually the ones the compiler uses, but are rather there for use by static verification tools like Dialyzer. Which means that the Erlang digraph doesn’t know how to topsort itself, even though there’s a module in the Erlang compiler application that does topsort on digraphs. Still feels like being a second-class citizen relative to the runtime’s favoured compiler.)

howenterprisey 7y ago

Does LLVM still take up much of the overall time spent by the Rust compiler? I was thinking of getting involved over there as the most effective way to make speed-ups happen.

rehemiau 7y ago
Probably yes, the LLVM linker is really slow
- mtzet 7y ago
  Really? I seem to recall lld being comparable to cp in speed, with the caveat that compacting debug strings can take a long time (if you enable that option). Reference: https://fosdem.org/2019/schedule/event/llvm_lld/ https://fosdem.org/2019/schedule/event/llvm_lld/
  - pornel 7y ago
    Depends on the platform and the build type. For example, on macOS in debug builds, the compiler and linker are reasonably fast, but then 2/3rds of the compilation time is spent in "dsymutil", presumably chewing through megabytes of the debug info.
- GrayShade 7y ago
  Rust is only using LLD on ARM targets.
  - est31 7y ago
    It's used on wasm as well.
nindalf 7y ago
I remember reading that it does, but because the LLVM IR generated by rustc is verbose. If less IR was generated, LLVM would have less work to do.

PunksATawnyFill 7y ago

What is Rust good for, as opposed to Swift or Kotlin?

pornel 7y ago

Faster compiler is nice, but you know what's faster? Not having to compile anything. I'm also looking forward to crates.io serving precompiled crates (https://www.ncameron.org/blog/cargo-in-2019/ https://www.ncameron.org/blog/cargo-in-2019/)

pjmlp 7y ago
Looking forward to it. If I would enjoy compiling everything from scratch I would be using Gentoo.
skunkpocalypse 7y ago
Ew, gross. Crates.io is already a security trainwreck in progress. Do we really need to add even more attack vectors? It's also solving a non-problem. I modify source code downloaded from crates.io zero times per day, so I compile each crate only once. Compile times matter for code I write myself: I modify (and therefore compile) that code dozens of times per day.
jazoom 7y ago
I'm a Rust noob but I think skunkopalypse was making some good points. I wish people didn't vote down his/her comment to death and actually replied to it so I could learn why he/she wasn't right.
- est31 7y ago
  I too think that precompiling crates won't really solve the problem. If you compare the compiled artifact (rlib) of a crate with the source code, you'll quickly see that the compiled artifact is much larger than the source code. libglutin-0c732c31a1d003fb.rlib has 8.1 MB while glutin-0.22.0-alpha1.crate has 53 KB. Most people have shitty internet. And often it's nothing you can do about it because you have shitty ISPs. You can buy a computer with good CPUs and those are usually cheaper in comparison than good internet for a year, at least in many rural areas in the US. It's not just the US, some other countries have it even worse. Now of course if you have good internet and a bad CPU it's a good deal, so there should definitely be an option to use it, maybe even with autodetection. But I think cargo has too much dependency on the internet, not too little. There should be no manual input required to turn off precompiled crates downloads if it is faster to compile the crates locally.

nn3 7y ago

1. make a really slow compiler 2. slightly improve it over time 3. write blogs about it 4. win? How about releasing software with reasonable performance in the first place? This was just discussed yesterday that everyone prefers faster software.

carlmr 7y ago
For most software I would agree with you. Usually you have some CRUD application where people don't know how to index and use hashing. But the Rust compiler is an amazing static analyzer. Running one on C++ to get the same level of memory safety will often take hours on sizeable projects.
- blub 7y ago
  A static analyzer which requires correct code to be rewritten in a certain way to satisfy the analyzer does not deserve to be called amazing.
  - oblio 7y ago
    Don't all static analyzers do that? Or they're just ignored, which happened in almost every large project I've ever seen.
    - carlmr 7y ago
      Exactly. C++ code has so much variability that 90% of static analyzer warnings are worthless. So people ignore them and create terrible unsafe code.
      - blub 7y ago
        My comment had nothing to do with C++ or any other particular language, you're using it as a red herring to divert attention from the fact that the Rust analyzer requires changing the way you write code, making it not awesome, but ordinary. And speaking of C++, it's obvious that Rust programmers take a very adversarial stance towards C++, but you should be instead thankful that it exists, because without it many of those marketing articles would lose their meaning. "Slow compiler is now less slow, but probably still slower than those of other languages you know" doesn't quite have the same effect.

pmoriarty 7y ago

I wish compiling the Rust compiler itself was faster. It literally takes days to compile on my old laptop.

cwp 7y ago
It is! The article is about the performance of the compiler, not the machine code it generates.
mitchty 7y ago
Try on arm! You'll wish you hadn't! >.< I think I spent 3-4 days compiling rust, almost forgot I started it at the time.
van2z 7y ago
Wait, what language were you compiling it on?
- zamadatix 7y ago
  Rust has been bootstrapped for a long time now.

johnklos 7y ago

Maybe they should make compiling the Rust compiler faster. Right now it takes longer and uses more CPU and memory than compiling a whole LLVM toolchain, then using that toolchain to compile a whole kernel and OS.

steveklabnik 7y ago
Compiling the Rust compiler also requires compiling LLVM, so by definition it will always take longer than that.