Live data from Hacker News

The Rust compiler is still getting faster

blog.mozilla.org

11–20 of 100 posts

Re: The Rust compiler is still getting faster

#11

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 softwar…

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.

Re: The Rust compiler is still getting faster

#12
post #8

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.

Probably yes, the LLVM linker is really slow

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/

Re: The Rust compiler is still getting faster

#13
post #2

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

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.

Re: The Rust compiler is still getting faster

#14
post #12
post #8

Earlier quoted context omitted.

Probably yes, the LLVM linker is really slow

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/

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.

Re: The Rust compiler is still getting faster

#16
post #15

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

Looking forward to it.

If I would enjoy compiling everything from scratch I would be using Gentoo.

Re: The Rust compiler is still getting faster

#17
post #11

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 softwar…

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.

Visual C++ may be great, but in practice, if you use it with MSBuild, you can't even build modules in parallel without manually tuning how many cores to allocate.

Re: The Rust compiler is still getting faster

#18
post #7

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 softwar…

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.

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

Re: The Rust compiler is still getting faster

#19
post #11

Earlier quoted context omitted.

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.

Visual C++ may be great, but in practice, if you use it with MSBuild, you can't even build modules in parallel without manually tuning how many cores to allocate.

Might be, but it already helps and there is IncrediBuild as part of the package.

Re: The Rust compiler is still getting faster

#20
post #2

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

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 le…

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

Post reply on HN