4 ms·

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 magnit

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?

mostlylurks 3y ago
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).
fcantournet 3y ago
You can install rust toolchain with https://rustup.rs/ 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.
llogiq 3y ago
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.
tczMUFlmoNk 3y ago
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 https://www.gnu.org/software/coreutils/#source [2]: https://github.com/uutils/coreutils https://github.com/uutils/coreutils
- herbstein 3y ago
  > 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.
  - tczMUFlmoNk 3y ago
    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.)
- PoignardAzur 3y ago
  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?
  - tczMUFlmoNk 3y ago
    No; sorry. Birthright only, I'm afraid.

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?

mostlylurks 3y ago

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

fcantournet 3y ago

You can install rust toolchain with https://rustup.rs/ 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.

llogiq 3y ago

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.

tczMUFlmoNk 3y ago

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 https://www.gnu.org/software/coreutils/#source [2]: https://github.com/uutils/coreutils https://github.com/uutils/coreutils

herbstein 3y ago
> 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.
- tczMUFlmoNk 3y ago
  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.)
PoignardAzur 3y ago
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?
- tczMUFlmoNk 3y ago
  No; sorry. Birthright only, I'm afraid.