Hacker News Reader

Comment by jonny383 | Hacker News Reader

How much slower is rust as opposed to C or C++ for production sized builds?

Traditionally people have thrown more hardware at these kinds of problems. As someone who has yet to use rust for anything more than small hobby sized projects, I am naive about rustic in terms of speed

View on HN

I think the range of compilation times for C and different styles of C++ is so huge that this question cannot be answered without going into a lot of details about how the C or C++ project is structured.

You can compile hundreds-of-thousands of lines of "user-side" C++ code in a few seconds, or in a few hours. The range is much smaller in most C projects, but can also differ by orders of magnitude.

In short, splitting a C++ project into many small source files (e.g. "one file per class") combined with using a lot of C++ stdlib headers in each small source file is the worst case for a C++ project because of all the complex stdlib template code that needs to be compiled over and over again. This can increase the "under-the-hood" line count by several hundred times (in Google Chrome, the amount of "project C++ code" is only 0.125% of all the code the compiler needs to compile when rebuilding the project because of included headers):

https://randomascii.wordpress.com/2020/03/30/big-project-bui...

AFAIK Rust solves part of this problem with its module system, but the compilation time problems lurk elsewhere.

Here's an interesting webpage which looks at compilation time of C++ stdlib headers and some popular 3rd-party libs:

https://artificial-mind.net/projects/compile-health/

IF I understand correctly, the borrow checker comes with some pretty severe compilation costs, since it requires a pretty wide level of code analysis, and might be single threaded.

Not generally, no. Or rather, there are other things that are a much bigger cost.

Rust's type system takes up a surprisingly small portion of compilation time. See the comment rooted at [0] for some discussion.

tl;dr: Profiling and tests show that codegen and LLVM work takes up the lion's share of compilation time. The borrow checker itself isn't that expensive in the grand scheme of things, and languages like OCaml show that it's very feasible to have a complex type system that compiles quickly.

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

From what I've heard they're roughly comparable, some projects will swing one way, some the other.

Rust has solid incremental compilation now though so you shouldn't be paying the price of a full rebuild often.

I had a quick search, but finding examples where the same project has been implemented in C++ and Rust with reported compile times seems to be rare...

There is a benchmark from way back in 2016 here: https://users.rust-lang.org/t/are-there-any-compilation-time...

Dev build was 2.91s for Rust vs 8.48s for C++, release build was 5.97s for Rust vs 9.79s for C++.

Would need to find much more recent examples for the comparison to be worthwhile.

That's a somewhat misleading comparison even for the time. All his C++ files could be compiled in parallel and recompiled incrementally, and his need for -flto to get good performance is really just due to how he structured his program. He seems to regard cpp files as the default location for functions and inlining as an optimization, but IMO it's the opposite. An empty function goes in the header, and every function starts off empty. You move it to a cpp file once it requires including a header. Moving a heavy function from a header to a cpp file is an action to optimize the compile time of your program.

On the other hand, it could be worse. There are some monstrously slow template libraries out there, and he's not using any of them. His code isn't very optimized, but it's sane.

The Rust compiler was far different in 2016, across a number of fronts. It's gotten significantly faster, as well as added a number of features to tweak compile times in various scenarios, like incremental compilation.

In my personal experience, Rustc is not slower than GCC or Clang. If anything, it may even be faster. If you transition from C++ to Rust, you don't need to worry about compile times. Obviously C compiles much faster than both C++ and Rust.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

This is a handy resource, though no benchmarks are ever perfect. Rust comes out faster on about half the algorithms. They're pretty close though.

I don't know why people feel the need to downvote instead of clarify, but this page is about runtime speed. The article is about compilation speed.

Thanks, I inferred incorrectly.

True, although for example:

n-body Rust #7 program 16.37s to complete and log all make actions

n-body C++ g++ #2 program 6.22s to complete and log all make actions

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Interesting - I didn't know the site gave those numbers at all. Obviously they are not the ones in the main comparisons.

Something seemed a bit weird with those numbers to me. My heavily loaded 2015 MacBook Air, which is also overheating, took <5s to compile nbody with the same Rust version and command line. The ratio remains about the same though - a similar GCC version is also much faster. Turns out, the hardware is really, really old ("Measured on a quad-core 2.4Ghz Intel® Q6600® with 3.8 GiB of RAM and 250GB SATA II disk drive; using Ubuntu™ 19.10 Linux x64 5.3.0-29-generic.").

> The ratio remains about the same though…

So for that back-of-the-envelope comparison of compile times (of 300 line tiny tiny programs) it really really doesn't matter that "the hardware is really, really old" :-)

It matters a lot for the absolute numbers. Apparently not for the relative ones (my measurements were super noisy though).

> How much slower is rust as opposed to C or C++ for production sized builds?

"relative ones" :-)

I'm not sure what you mean. The absolute difference appears to have shrunk considerably vs old hardware, based on this single, unreliable example. Probably most people care more about that than the relative difference? It's not explicit in the question (and neither are the benchmarks production-sized builds).

> It's not explicit in the question…

True.

Although if jonny383 actually wanted to know how many seconds then shouldn't our answer be — it depends.

Reply on news.ycombinator.com