3 ms·

Rust has great support for modules (crates in Rust lingo). It can compile modules in parallel when they don't depend on each other. The problem is that when yo

by roca 6y ago

Rust has great support for modules (crates in Rust lingo). It can compile modules in parallel when they don't depend on each other. The problem is that when you have module A depending on module B, rustc doesn't do a good job of compiling A and B in parallel. In contrast, in C/C++ you can handcraft your header files to ensure that A and B compile in parallel.

pjmlp 6y ago
In C and C++ it is also quite common to use binary dependencies, something that cargo still doesn't do. However C++ is also now looking at parallelization opportunities for modules, which is a similar situation as crates.
- fluffything 6y ago
  Every time you compile a rust project after an initial compile, cargo does use "binary" dependencies (bitcode dependencies). It is much better at this than C++. For example, change a trait in your Rust library, and recompile the tests, and compare that with changing a type in, say, range-v3 (or any other C++ header-only library). In C++, recompiles take pretty much the same time as clean builds (for range-v3, exactly the same time). In Rust, they are infinitely faster (100000x faster, depending on the project, but essentially almost instant, in contrast with initial compiles). So for development at least I'll pick Rust over C++ every day. I only do an initial compile once, but I edit and recompile a lot, and that's the bottleneck that I really care about. (Same with C btw, add a new API to a commonly use C header and re-compile, and you end up re-compiling the world, while from Rust, you just re-compile the part of the crate where the new API was added, and since no downstream crates use it, that's pretty much it - instant change).
boris 6y ago
Actually, rustc produce a crate metadata (those .rmeta files) which is all that's needed to start compiling dependent crates. Producing this metadata is pretty quick compared to producing the finished crate.
- roca 6y ago
  Right, but still, compiling long dependency chains is slow :-(.

by roca 6y ago

pjmlp 6y ago

In C and C++ it is also quite common to use binary dependencies, something that cargo still doesn't do. However C++ is also now looking at parallelization opportunities for modules, which is a similar situation as crates.

fluffything 6y ago
Every time you compile a rust project after an initial compile, cargo does use "binary" dependencies (bitcode dependencies). It is much better at this than C++. For example, change a trait in your Rust library, and recompile the tests, and compare that with changing a type in, say, range-v3 (or any other C++ header-only library). In C++, recompiles take pretty much the same time as clean builds (for range-v3, exactly the same time). In Rust, they are infinitely faster (100000x faster, depending on the project, but essentially almost instant, in contrast with initial compiles). So for development at least I'll pick Rust over C++ every day. I only do an initial compile once, but I edit and recompile a lot, and that's the bottleneck that I really care about. (Same with C btw, add a new API to a commonly use C header and re-compile, and you end up re-compiling the world, while from Rust, you just re-compile the part of the crate where the new API was added, and since no downstream crates use it, that's pretty much it - instant change).

boris 6y ago

Actually, rustc produce a crate metadata (those .rmeta files) which is all that's needed to start compiling dependent crates. Producing this metadata is pretty quick compared to producing the finished crate.

roca 6y ago
Right, but still, compiling long dependency chains is slow :-(.