[partitioning] Add heuristic for size of MIR and use it to partition CGUs more evenly. #47316
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
E-easy
Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
I-compiletime
Issue: Problems and improvements with respect to compile times.
Comments
michaelwoerister
added
E-easy
varkor
added a commit
to varkor/rust
that referenced
this issue
Jan 19, 2018
This addresses the concern of rust-lang#47316 by estimating CGU size based on the size of its MIR. Looking at the size estimate differences for a small selection of crates, this heuristic produces different orderings, which should more accurately reflect optimisation time. Fixes rust-lang#47316.
bors
added a commit
that referenced
this issue
Jan 25, 2018
…ster Add CGU size heuristic for partitioning This addresses the concern of #47316 by estimating CGU size based on the size of its MIR. Looking at the size estimate differences for a small selection of crates, this heuristic produces different orderings, which should more accurately reflect optimisation time. (Fixes #47316.) r? @michaelwoerister
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jan 25, 2018
…ichaelwoerister Add CGU size heuristic for partitioning This addresses the concern of rust-lang#47316 by estimating CGU size based on the size of its MIR. Looking at the size estimate differences for a small selection of crates, this heuristic produces different orderings, which should more accurately reflect optimisation time. (Fixes rust-lang#47316.) r? @michaelwoerister
bors
added a commit
that referenced
this issue
Jan 26, 2018
…ster Add CGU size heuristic for partitioning This addresses the concern of #47316 by estimating CGU size based on the size of its MIR. Looking at the size estimate differences for a small selection of crates, this heuristic produces different orderings, which should more accurately reflect optimisation time. (Fixes #47316.) r? @michaelwoerister
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The compiler usually splits the program into multiple codegen units, so LLVM can optimize them in parallel. The way it does this is by starting out with one codegen unit at per
modand then repeatedly merging the two smallest CGUs until the desired number of CGUs has been reached.However, the way we define "smallest" is very simplistic: We just take the number of translation items in a CGU as its "size", not taking into account the size of each translation item. So a CGU with two one-line functions is considered bigger than a CGU with one 1000-line function.
It should be possible to make this heuristic more accurate without incurring much complexity. One way to start would be to estimate the size of each translation item by looking at its MIR. Just counting the statements would be an improvement over the current situation.
More evenly sized CGUs can potentially improve compile times by preventing situations where all but one thread are sitting idle, waiting for a single oversized CGU to be optimized.
The text was updated successfully, but these errors were encountered: