I'm not sure this is an interesting direction. Isn't Rust compilation already highly-parallel at the file level? Sure if a single file compiles faster that nice. But won't this steal resources from the top-level file parallelism? I find it quite concerning that there are no numbers given for that.
Today, Rust compilation is parallel in the front-end at the crate level, not file or even module level. Large crates will therefore not benefit from parallelism, and splitting a large crate into smaller ones comes with its own costs too.
This, however, doesn't apply to the code generation phase with LLVM which is already parallelizable at the codegen unit level (the number of codegen units is configurable), but that's the “back-end”, whereas this new parallelization applies to the “front-end” of the compiler.
> Today, Rust compilation is parallel in the front-end at the crate level, not file or even module level. Large crates will therefore not benefit from parallelism,
Sort of, it's managed at the crate level and not file or module indeed, but the compiler then splits crates into smaller chunks called “codegen units”.
> This flag controls the maximum number of code generation units the crate is split into. […] When a crate is split into multiple codegen units, LLVM is able to process them in parallel. […]
The default value is 16 for non-incremental builds. For incremental builds the default is 256 which allows caching to be more granular.
> This, however, doesn't apply to the code generation phase with LLVM which is already parallelizable at the codegen unit level (the number of codegen units is configurable), but that's the “back-end”, whereas this new parallelization applies to the “front-end” of the compiler.
It’s not. Rust compilation is currently parallel at the _crate_ level (i.e. one crate is one translation unit). Speeding up compilation of large crates could lead to nice speedups.
> But won't this steal resources from the top-level file parallelism?
It won’t. rustc uses jobserver protocol to coordinate parallelism with cargo, so the total amount of threads doing compilation of the whole project doesn’t exceed CPU count.
Anyone who has tried to compile Rust projects on a system with many cores while running htop could tell you that it spends a whole lot of time using only a few cores. Remember, Rust is not like C where the interface definitions (header files) exist on disk so all files can be compiled completely independently.
