
The Rust compiler is still getting faster - nnethercote
https://blog.mozilla.org/nnethercote/2019/07/25/the-rust-compiler-is-still-getting-faster/
======
fluffything
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.

~~~
pjmlp
Visual C++ is part of those few.

Rust is still far from Delphi, Eiffel, .NET Native experience though.

Although it is great that it keeps improving.

~~~
fluffything
Is there a blog post about Visual C++ being multi-threaded end-to-end ? (e.g.
doing parsing, type-checking, etc. of a single TU in parallel using all cores
?)

That would be super interesting to read because it is mainly a C++ compiler
and some C++ features like two-phase lookup and macros make it quite hard to
do things in parallel. You have to do things in a certain order but I suppose
that if its query-based as well it will work.

The only option I know is /CGTHREADS but that only uses multiple-threads for
optimizations and code generation which is something that the Rust compiler
has been able to do for a very long time (e.g. there these are called codegen-
units and LLVM supports these so it is quite trivial for a frontend to do so
as well).

~~~
zone411
As the documentation says: "The /MP (Build with Multiple Processes) compiler
flag specifies the number of cl.exe processes that simultaneously compile the
source files. The /cgthreads option specifies the number of threads used by
each cl.exe process." I've never used /CGTHREADS but /MP is working well
(except for the precompliled header file).

~~~
virgilp
That's for different source files though, right? Try having a 10Mb auto-
generated C++ file, see how fast it compiles, regardless how powerful your
computer is.

~~~
fluffything
No need to autogenerate anything: expand all headerfiles into a .cpp file, and
you easily end up with > 10Mb files.

Visual C++ pre-compiled headers is quite amazing and works really great,
avoiding this almost completely.

------
sddfd
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).

~~~
fluffything
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
> 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
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
> \- 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
So I manage to get it to work in the command line using `CXXFLAGS="$CXXFLAGS
-fsyntax-check" cmake ... && make` !

~~~
gpderetta
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.

------
pornel
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/))

~~~
jazoom
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
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.

------
howenterprisey
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.

~~~
nindalf
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.

~~~
masklinn
I think that's one of the eventual purposes of MIR (by both optimising Rust
upstream from the LLVM IR generation and having a much simpler language to
generate IR for), but I don't know if there's been work towards that yet.

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

~~~
van2z
Wait, what language were you compiling it on?

~~~
zamadatix
Rust has been bootstrapped for a long time now.

------
johnklos
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
Compiling the Rust compiler also requires compiling LLVM, so by definition it
will always take longer than that.

