Hacker News Reader

Hacker News

Comment by Laaas | Hacker News Reader

Full thread

Laaas

The issue with Rust is the horrible compile times.

I actively avoid Rust projects because they take too long to compile.

I wish rustc had an option for disabling monomorphization, a true -Os option.

View on HN

According to pcwalton appears avoiding monomorphization on its own may be unlikely to yield substantial gains [0]:

> I doubt that a hypothetical version of Rust that avoided monomorphization would compile any faster. I remember doing experiments to that effect in the early days and found that monomorphization wasn't really slower. That's because all the runtime bookkeeping necessary to operate on value types generically adds up to a ton of code that has to be optimized away, and it ends up a wash in the end. As a point of comparison, Swift does all this bookkeeping, and it's not appreciably faster to compile than Rust; Swift goes this route for ABI stability reasons, not for compiler performance.

> What you would need to go faster would be not only a non-monomorphizing compiler but also boxed types. That would be a very different language, one higher-level than even Go (which monomorphizes generics).

[0]: https://news.ycombinator.com/item?id=38224941

Compile times have greatly improved over the last few years. And if you aren't importing 100+ dependencies from Cargo.toml or using a lot of templates/traits (which I suspect kernel code won't), then it's even better.

Edit: Also kernel compile times are a problem for the elite few, while kernel bugs are a problem for everyone.

Aren't common libraries like serde and clap known to slow down compile times?

Yes, but Rust for Linux won’t be using these kinds of dependencies.

That's a good point. Rust in the Kernel is different from the general ecosystem.

The first time you build, sure but that’s true for C/C++ applications too (boost command_line or applications with lots of protobufs). Overall my experience that build times on Rust are waaaaaay better than C++ all things being equal (i.e. similar level of features). And honestly the developer experience of clap I’ve found to be a lot faster to work with than equivalent libraries in TypeScript which is saying something considering the typing on Rust is a lot more strict and cumbersome to work with.

Yes, but not substantially - at least in comparison to *-sys crates which (surprise!) compile C/C++ most of the time.

Compared to C, yes. However the tradeoff you get is tighter iteration, with more errors being found at compile-time rather than having to wait for runtime.

If you have to restart an embedded system or schedule a job on a cluster to properly test, that can work out to huge savings.

It would still be nice to see them substantially improve. I know there’s been effort to get debug mode to build substantially faster with cranelift, but I forget if that’s in stable now.

Indeed, I'm merely complaining as an entitled end-user. As a developer Rust is much better than C.

What are you compiling? I've "cargo install"-ed - which means deps had to be built too - two rust tools today on a 4c/8t laptop and they were done in maybe two minutes each. Building AUR packages of some C tools isn't much faster in comparison.

It's way faster than C++ - doubly so if you count "time spent grokking a compiler error" - and if that's the other option (it usually is), I'll take Rust

I agree it's faster than C++, but Linux is written in C which is much faster the C++ or Rust.

Still, I would say Rust is fast enough now that compile time isn't a show stopper.

If you spend enough time with C++ you become a compiler error transpiler that converts 100 lines of angle-bracket spam into what it 'really' means.

I eventually got to that point, but my doctor said the ulcer was getting out of control

True, but I've been highly bullish on that: if that's a core complaint, it seems one of the easier ones to improve in the medium term.

A host of other issues, which Rust notably doesn't suffer from, are almost "unfixable", even in the long term: think build system, type system, memory safety. Rust is fine in these regards.

I haven’t done any Rust-on-Linux development, but it seems like this would be a non-issue there? A lot of the compile time issues for Rust come from cargo packages pulling in tons of monomorphized types, but I assume Rust-on-Linux has few-to-no dependencies (I’m pretty sure they don’t even use the standard library).

Yeah, when I’m doing zero-dependency development my compile times from scratch are never more than 5 seconds.

Standard library actually shouldn’t increase compile time at all really, since it’s prebuilt and included for most platforms (excepting -Z build-std).

I didn't mean to imply that the Rust standard library increases compile times, just that Rust-on-Linux is so dependency-lite (as evidenced by the lack of std) that I expect compile times to be good.

True, I just mentioned that because it's bitten me before and I didn't expect it at all :)

How much longer does `rustc` typically take to compile the same programming tasks compared to `gcc`? Is it just "a bit" e.g. 50% slower or by an order of magnitude?

It's not about the compiler, it's about the language. Rust, and C++ as well, have features that generally speaking require the compiler to do a significant amount of work to compile the program. Plain old C can easily compile more than an order of magnitude faster than an equivalent idiomatic Rust or C++ program, even if compiled with the same compiler suite (gcc).

You can install rust toolchain with https://rustup.rs/ in 1 minute, and git clone some project to see for yourself. It's impossible to answer your question directly, as it depends a lot on dependencies and language features.

That very much depends on the code you're compiling. The factors that come into play are monomorphization (which means the compiler builds one copy of the code per type it is called for), procedural macros (which need to be fully compiled before being able to expand code using them), whether complex type shenanigans are used, etc. etc. Absent that, Rust will compile roughly as fast as C nowadays.

I thought this was an interesting question, so I just compared GNU coreutils [1] and the uutils/coreutils Rust implementation [2]. I've never built either of these projects before, but I was able to easily build them both within a few minutes. I think they're of comparable size: uutils/coreutils has 102 coreutils programs, whereas GNU coreutils has 109 programs. And I liked your phrasing of testing the "same programming tasks": I'm sure that these projects have different implementation styles and philosophies, but at the end of the day they're both trying to implement a similar set of utilities.

My hardware is an 11th gen Intel i7 (4-core, 8-thread) laptop. I included time to build but did excluded time to fetch dependencies. I measured real (wall) time and user time with time(1). I compiled clean release builds in both cases (I think). Here's what I found:

uutils/coreutils: I fetched dependencies (`cargo fetch`) ahead of time, then just ran `time cargo build --release` to build everything. This took 1m37s wall time, 4m19s user time. It looked like about half of that time was spent compiling the `coreutils` multicall (Busybox-style) binary itself, after compiling all the individual `uu_*` utilities (`uu_cat`, etc.).

GNU coreutils: I fetched dependencies (`git submodule update --init --recursive`) ahead of time, then read `README-hacking`, which indicates a three-step build process:

    time ./bootstrap: 2m42s wall time, 4m32s user time
    time ./configure: 0m36s wall time, 0m21s user time
    time make -j8:    0m21s wall time, 2m24s user time

I don't know exactly what ./bootstrap is doing? It's a 1500-line shell script. It does seem to download pofiles at the start, so knock 10s off its runtime. A lot of its time seems to be spent in gnulib-tool(1); it runs aclocal(1) and m4(1) near the end, but I didn't notice it running cc(1). (I'm just watching top.) Maybe someone who knows this codebase better can comment how to fairly compare these.

So, if we're measuring "time for clean release build on a new dev's machine (not including network fetches)", we're looking at ~200s for GNU coreutils and 97s for uutils/coreutils. If we discount ./bootstrap for whatever reason, that goes down to 57s vs. 97s. Either way, it seems within a factor of roughly 2, with the winner going one way or another depending on how you count.

Methodology comments welcome.

[1]: https://www.gnu.org/software/coreutils/#source

[2]: https://github.com/uutils/coreutils

> It looked like about half of that time was spent compiling the coreutils multicall (Busybox-style) binary itself

Using a different linker (like mold) might change that, if most of the time is spent linking everything together.

mold didn't seem to help very much, surprisingly! (97s -> 90s.) I checked that it did actually make it into the linker pipeline:

    $ readelf -p .comment ./target/release/coreutils 

    String dump of section '.comment':
      [     0]  rustc version 1.74.0 (79e9716c9 2023-11-13)
      [    2c]  GCC: (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0
      [    57]  mold 2.3.3 (49066ea329979c3187556091ba62421594799fd1; compatible with GNU ld)
      [    a6]  GCC: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

I may have done something wrong; let me know if you get substantially different results.

(Edited for new timings with mold 2.3.3 instead of 1.0.3.)

You... you mean you actually tried to run things? And then looked at the results, instead of just speculating about them?

Can this power be learned?

No; sorry. Birthright only, I'm afraid.

Is there evidence that Rust compiles any slower than C++? Granted, it doesn't compile at the speed of C, but it does a lot more and you can write a lot denser code, so one line of Rust may easily supplant dozens of lines of C.

The only problem with Rust is that it has ALGOL syntax. If it had Lisp syntax it would be the perfect language.

Reply on news.ycombinator.com