Skip to content

rustbuild: Disable multiple CGUs in stable release builds #45444

Closed

Description

@petrochenkov

#45400 enabled multiple CGUs + ThinLTO in rustc builds to speedup bootstrap, however it made the produced compiler slower (see #45400 (comment) and below).

This is desirable for development builds, where build times are priority, but not for stable release builds that happen rarely (so build times don't matter much) and produce binaries used by majority of Rust users.

Enabling full LTO (#45400 (comment)) in stable release builds is also worth investigating.

Activity

  1. added
    T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
    T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.
    on Oct 22, 2017
  2. Mark-Simulacrum commented on Oct 23, 2017

    @Mark-Simulacrum
    Member

    Responding to @michaelwoerister from this comment:

    I agree that we should build stable and beta releases with just one CGU and whatever other performance optimization we can do. I think the only reason we don't use regular LTO for stable releases is that rustc is built out of Rust dylibs which are incompatible with LTO.

    I'm personally not opposed to shipping faster stable/beta artifacts -- we already do this by disabling LLVM assertions for example, so I don't see why disabling ThinLTO is a bad thing here. Seems like a fairly clear win, at least until ThinLTO is no longer a loss.

    @alexcrichton, @Mark-Simulacrum, do we have numbers on how this influences build times in CI?

    Not that I know of. Travis is problematic due to running our builds always at least once extra and often more than that, but we may be able to get data from @aidanhs. I'd also be interested in relative performance increases locally (building the compiler itself) but that just needs someone to be patient enough to rebuild the compiler with and without this patch.

  3. michaelwoerister commented on Oct 23, 2017

    @michaelwoerister
    Member

    I'm personally not opposed to shipping faster stable/beta artifacts -- we already do this by disabling LLVM assertions for example

    That would have been my line of argument too.

  4. alexcrichton commented on Oct 23, 2017

    @alexcrichton
    Member

    Yes as @michaelwoerister mentioned the current design with dylibs inhibits full LTO (in general procedural macros throw a wrench into full LTO).

    For disabling multiple CGUs/ThinLTO it seems fine to do that on release builds which as mentioned already have other tweaks anyway.

  5. modified the milestones: 1.22, 1.21 on Oct 23, 2017
  6. aidanhs commented on Oct 24, 2017

    @aidanhs
    Contributor

    I might be able to get some stats if you let me know what you'd like to compare - before and after a particular commit I assume? There's a lot of noise in Travis (particularly at the moment) so there may not be very high quality results.

  7. modified the milestones: 1.22, 1.23 on Nov 15, 2017
  8. Mark-Simulacrum commented on Nov 15, 2017

    @Mark-Simulacrum
    Member

    Increasing priority to high as I'd prefer that beta didn't have this, but if it slips that doesn't seem to bad as we'll be fine for one more cycle.

  9. Mark-Simulacrum commented on Jan 15, 2018

    @Mark-Simulacrum
    Member

    @alexcrichton So if I'm correct at least the last stable release shipped with this? I don't think there's been any movement yet... I can probably make an implementation if we'd like to make beta/stable builds get built without ThinLTO. Is that the consensus?

  10. alexcrichton commented on Jan 16, 2018

    @alexcrichton
    Member

    @Mark-Simulacrum hm maybe? I'm not sure myself.

    In any case seems fine to draft a patch!

  11. Mark-Simulacrum commented on Jan 16, 2018

    @Mark-Simulacrum
    Member

    I'll assign myself and try to get a patch up soon.

  12. added
    C-enhancementCategory: An issue proposing an enhancement or a PR with one.
    on Jan 24, 2018
  13. nikomatsakis commented on Jan 25, 2018

    @nikomatsakis
    Contributor

    It's hard for me to get a sense of how big the regression actually is. @alexcrichton suggests pretty small? In any case, I do think it makes sense to make our artifacts as good as they can be.

  14. alexcrichton commented on Jan 25, 2018

    @alexcrichton
    Member

    @nikomatsakis IIRC yes it was ~5% at most in some cases

  15. removed this from the 1.23 milestone on Jan 28, 2018
  16. added 3 commits that reference this issue on Feb 2, 2018
    d2192a1
    20e1b39
    0c6091f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

C-enhancementCategory: An issue proposing an enhancement or a PR with one.P-highHigh priorityT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions