Add appropriate resource set for Rustc `codegen-units`

[UebelAndre]

https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units

This flag controls the maximum number of code generation units the crate is split into. It takes an integer greater than 0.

When a crate is split into multiple codegen units, LLVM is able to process them in parallel. Increasing parallelism may speed up compile times, but may also produce slower code. Setting this to 1 may improve the performance of generated code, but may be slower to compile.

The default value, if not specified, is 16 for non-incremental builds. For incremental builds the default is 256 which allows caching to be more granular.

If this is true, then by default, a single Rustc action consumes 16 CPU and should be reflected in Bazel's scheduling. An alternative is to force this value to be 1.

[freeformstu]

I really don't think you should force it to be 1, that will significantly slow down compile times.

My suggestion would be to set codegen-units equal to the number of .rs files with a configurable min/max. Since rust defaults to 16, 16 should probably be the default floor (although I'd certainly be open to setting this lower for small crates if the performance difference is negligible). If you have a massive crate (dozens of files or more), setting this higher should definitely help. Memory should similarly be scaled as well. Obviously this is an imprecise approximation because you could have a crate with one massive file in which case you should probably set this value explicitly on that rule.

I'm not sure what configuration options exist for parallelizing linking but I'm fairly certain a lot of our larger crate's slow build times are a result of slow linking (eg. binary rules are often a single file but have many dependencies). If there's any way to increase parallelism in the same way (based on number of dependencies in this case) that would be fantastic.

[UebelAndre]

cc @hlopko @scentini @krasimirgg wondering if you folks have any thoughts too.

[UebelAndre]

An alternative is to force this value to be 1.

Also to clarify, it should be forced to match Bazel's expectation, which is 1 CPU per action. I'm not advocating for this to be forced to 1 as a reasonable default. I just want the scheduling to be representative.

[havasd]

I think it is 2-fold.

We use codegen-units=1 in our toolchain because of optimization reasons (it doesn't seem too slow).
However, we run linker as part of rustc as well afaik. Because of static linking for binaries that is a heavy deal and imho it is beneficial to allow linker accessing more resources otherwise we that can get really slow

[UebelAndre]

I think it is 2-fold.

We use codegen-units=1 in our toolchain because of optimization reasons (it doesn't seem too slow). However, we run linker as part of rustc as well afaik. Because of static linking for binaries that is a heavy deal and imho it is beneficial to allow linker accessing more resources otherwise we that can get really slow

Sorry, what's 2-fold? Are you saying Rustc actions currently have 2 different consumers of CPU cores? The compiler and the linker?

[havasd]

Correct, if I understand correctly the rules_rust code. It is using single rustc action to build the rust code and link the binary.

Limiting CPU resources can be especially problematic for rust_binary rules, as those tend to be heavy on the linking side even though the compilation and codegen might be lightweight.

Enabling LTO, increases the linking times dramatically where this "exploitation" of CPU resources can come in handy as today's linker can parallelize linking much better.

Potential solution can be to split the codegen and linking into separate actions so that codegen can be restricted with resources properly.

[UebelAndre]

Potential solution can be to split the codegen and linking into separate actions so that codegen can be restricted with resources properly.

This sounds like a great idea but I haven't looked into that before. I know there's --@rules_rust//rust/settings:experimental_use_cc_common_link which I do believe does that but I've never used it before so don't have full context.

That being said, adding resource_set doesn't prevent an action from consuming more than the resources described, it just helps Bazel with scheduling actions such that your machine isn't overwhelmed. This is the part I primarily care about. If we wanna split up Rustc actions or allocate resources based on the max of compile+linking actions and keep them in the same action then I'm fine with either!