Skip to content

2025h2: SVE + build-std + rustc-perf-improvements #331

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

2025h2: SVE + build-std + rustc-perf-improvements #331

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
629b283
2025h2: Arm's goals
davidtwco Jun 20, 2025
caf21ee
2025h2: finish rustc-perf goal description
davidtwco Jun 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
166 changes: 166 additions & 0 deletions src/2025h2/build-std.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,166 @@
# build-std

| Metadata | |
| :-- | :-- |
| Point of contact | @davidtwco |
| Teams | <!-- TEAMS WITH ASKS --> |
| Task owners | <!-- TASK OWNERS --> |
| Status | Proposed |
| Zulip channel | N/A |
| Tracking issue | [rust-lang/rust-project-goals#274] |

## Summary

Over the next six months, we will continue our efforts to write an RFC for a
minimum viable product (MVP) of build-std which has the potential to be
stabilised once implemented (as opposed to the currently implemented MVP which
is only suitable for experimentation and testing), and then implement it.

## Motivation

build-std is a well-known unstable feature in Cargo which enables Cargo to
re-build the standard library, this is useful for a variety of reasons:

- Building the standard library for targets which do not ship with a
pre-compiled standard library.
- Optimising the standard library for known hardware, such as with non-baseline
target features or options which optimise for code size. This is a common use
case for embedded developers.
- Re-building the standard library with different configuration options (e.g.
changing the optimisation level, using flags which change the ABI, or which
add additional exploit mitigations).
- Re-building the standard library with different `cfg`s (e.g. disabling
`backtrace` in std), to the extent that such configurations are supported by
the standard library.
- Stabilisation of various compiler flags which change the ABI, add additional
exploit mitigations (such as `-Zsanitizers=cfi` or `-Zbranch-protection`), or
which otherwise only make sense to use when the entire program is compiled
with the flag (including std) is blocked on these being unable to be used
properly without being able to rebuild std.

These features are more useful for some subsets of the Rust community, such as
embedded developers where optimising for size can be more important and where
the targets often don't ship with a pre-compiled std.

The fifty-thousand foot view of the work involved in this feature is:

- Having the standard library sources readily available that match the compiler.
- Being able to build those sources without using a nightly toolchain, which has
many possible solutions.
- Having a blessed way to build at least `core` without Cargo, which some users
like Rust for Linux would like.
- This would be optional but may be a side-effect of whatever mechanism for
build-std the MVP RFC eventually proposes.
- Being able to tell the compiler to use the resulting prebuilt standard library
sources instead of the built-in standard library, in a standard way.
- Integrating all of the above into Cargo.
- Making sure all of this works for targets that don't have a pre-built std.

Rust for Linux and some other projects have a requirement to build core
themselves without Cargo (ideally using the same stable compiler they use for
the rest of their project), which is a shared requirement with build-std, as
whatever mechanism these projects end up using could be re-used by the
implementation of build-std and vice-versa.

### The status quo

build-std is currently an unstable feature in Cargo which hasn't seen much
development or progress since its initial development in 2019/2020. There are a
variety of issues in the [wg-cargo-std-aware][wg-cargo-std-aware] repository
which vary from concrete bugs in the current experimental implementation to
vague "investigate and think about this" issues, which make the feature
difficult to make progress on.

Some of the work required for this exists in the current perma-unstable
`-Zbuild-std` implementation, which may be re-used if appropriate.

In 2025H1, the goal owners established a regular sync meeting with liasons from
the library, compiler and Cargo teams which have been successful in creating a
draft RFC that continues to be iterated on and refined before being shared with
the broader project.

[wg-cargo-std-aware]: https://github.com/rust-lang/wg-cargo-std-aware

### The next 6 months

There are two primary objectives of this goal in its first six months:

- Continue to refine and draft a complete RFC for build-std, including a
detailed history of the feature and surrounding discussions going back to its
origins in 2015.
- Next, after and conditional on acceptance of the RFC, proceed with its
implementation.

As part of the goal, the goal owners will regularly be in contact with representatives from
relevant teams in our regular sync call established during the 2025H1 goal period, and will commit
to posting updates on our progress on a monthly basis.

### The "shiny future" we are working towards

After the approval and implementation of the MVP RFC, there will naturally be
follow-up use cases which can be designed and implemented to complete the
build-std feature.

## Design axioms

- Enabling build-std without changing any compilation options or configuration
should produce an equivalent library to that distributed by the project.
- Avoid precluding future extensions to build-std.
- build-std should allow std/alloc/core to be treated more like other
dependencies than currently.
- This represents a general move away from treating std/alloc/core as a
special case.

## Ownership and team asks

| Task | Owner(s) or team(s) | Notes |
| ---------------------------- | ------------------------------------- | ------------------------------------------------------------------- |
| Discussion and moral support | ![Team][] [cargo], [libs], [compiler] | @ehuss, @joshtriplett and @wesleywiser already regularly contribute |
| Author RFC | @davidtwco, @adamgemmell | Continue draft produced in 2025H1 |
| Design meeting | ![Team][] [cargo], [libs], [compiler] | Review initial RFC draft |
| RFC decisions | ![Team][] [cargo], [libs], [compiler] | Decide to approve RFC. |
| Implementation | @davidtwco, @adamgemmell | |
| Standard reviews | ![Team][] [cargo], [libs], [compiler] | |

### Definitions

Definitions for terms used above:

* *Discussion and moral support* is the lowest level offering, basically
committing the team to nothing but good vibes and general support for this
endeavor.
* *Author RFC* and *Implementation* means actually writing the code, document,
whatever.
* *Design meeting* means holding a synchronous meeting to review a proposal and
provide feedback (no decision expected).
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
* *Org decisions* means reaching a decision on an organizational or policy
matter.
* *Secondary review* of an RFC means that the team is "tangentially" involved in
the RFC and should be expected to briefly review.
* *Stabilizations* means reviewing a stabilization and report and deciding
whether to stabilize.
* *Standard reviews* refers to reviews for PRs against the repository; these PRs
are not expected to be unduly large or complicated.
* *Prioritized nominations* refers to prioritized lang-team response to
nominated issues, with the expectation that there will be *some* response from
the next weekly triage meeting.
* *Dedicated review* means identifying an individual (or group of individuals)
who will review the changes, as they're expected to require significant
context.
* Other kinds of decisions:
* [Lang team experiments][experiment] are used to add nightly features that
do not yet have an RFC. They are limited to trusted contributors and are
used to resolve design details such that an RFC can be written.
* Compiler [Major Change Proposal (MCP)][mcp] is used to propose a 'larger
than average' change and get feedback from the compiler team.
* Library [API Change Proposal (ACP)][acp] describes a change to the
standard library.

[experiment]: https://lang-team.rust-lang.org/how_to/experiment.html
[mcp]: https://forge.rust-lang.org/compiler/mcp.html
[acp]: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html

## Frequently asked questions

None yet.
132 changes: 132 additions & 0 deletions src/2025h2/rustc-perf-improvements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,132 @@
# rustc-perf improvements

| Metadata | |
| :-- | :-- |
| Point of contact | @Jamesbarford |
| Teams | <!-- TEAMS WITH ASKS --> |
| Task owners | <!-- TASK OWNERS --> |
| Status | Proposed |
| Zulip channel | [#project-goals/2025h1/rustc-perf-improvements][channel] |
| Tracking issue | [rust-lang/rust-project-goals#275] |

[channel]: https://rust-lang.zulipchat.com/#narrow/channel/478771-project-goals.2F2025h1.2Frustc-perf-improvements

*This goal will be primarily worked on by @Jamesbarford, but @davidtwco or
@Kobzol can always be contacted for updates.*

## Summary

Continue our efforts from 2025H1 to add support to rustc-perf for distributed
benchmarking across multiple platforms and configuration.

## Motivation

Improving the performance of the Rust compiler is a long-standing objective of
the Rust project and compiler team, which has led to the development of the
project's performance tracking infrastructure. While the performance tracking
infrastructure has seen many improvements in recent years, it cannot scale to
support multiple benchmarking machines simultaneously.

There are increasingly demands on the performance infrastructure which require a
more scalable benchmarking infrastructure - benchmarking the parallel compiler
with different thread counts, different codegen backends, or different
architectures.

### The status quo

rustc-perf does not yet support scheduling or accepting benchmarks from
multiple machines.

To ensure ongoing changes don't break existing functionality, tests have
been added to guard the current system. Notable progress includes the
introduction of database tests and incremental improvements to error
handling in the new system.

A new system architecture has been outlined in this
[design document][design_doc] of which progress has commenced in implementing
it. The new system will operate in parallel with the existing one until we
are confident it can fully replace it. rustc-perf does not currently support
scheduling and accepting benchmarks from multiple machines, requiring a
non-trivial rearchitecting to do so. None of our policies around performance
triage and handling regressions currently consider what to do in case of
conflicting benchmarking results.

[design_doc]: https://hackmd.io/wq30YNEIQMSFLWWcWDSI9A

### The next 6 months

This period is a continuation of the previous six months, during which
meaningful progress was made in beginning the implementation of a new system
for rustc-perf.

* Switch the default collector to the new AX-42, initially running on the
legacy non-parallel system.
* Enable benchmarking to run in parallel across multiple collectors.
* Continue expanding test coverage for the new distributed rustc-perf
infrastructure to reduce the risk of future regressions.
* Build a status page to display the health of each collector.
* Add support for benchmarking on AArch64 as a separate architecture.
* Enhance perf.rust-lang.org to display performance data from multiple
collectors, with the ability to compare results within a given configuration
(not across different configurations).

### The "shiny future" we are working towards

Following the completion of this goal, it is anticipated that new platforms and
configurations will be added to rustc-perf, but this is unlikely to warrant
further goals.

## Ownership and team asks

| Task | Owner(s) or team(s) | Notes |
|-----------------------------------------------|------------------------|-------------------------------------------------|
| Discussion and moral support | ![Team][] [infra] | |
| Improve rustc-perf implementation work | @Jamesbarford, @Kobzol | |
| Standard reviews | ![Team][] [infra] | |
| Deploy to production | ![Team][] [infra] | rustc-perf improvements, testing infrastructure |
| Draft performance regression policy | @davidtwco | |
| Policy decision | ![Team][] [compiler] | Update performance regression policy |
| Inside Rust blog post announcing improvements | @Kobzol, @davidtwco | |

### Definitions

Definitions for terms used above:

* *Discussion and moral support* is the lowest level offering, basically
committing the team to nothing but good vibes and general support for this
endeavor.
* *Author RFC* and *Implementation* means actually writing the code, document,
whatever.
* *Design meeting* means holding a synchronous meeting to review a proposal and
provide feedback (no decision expected).
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
* *Org decisions* means reaching a decision on an organizational or policy
matter.
* *Secondary review* of an RFC means that the team is "tangentially" involved in
the RFC and should be expected to briefly review.
* *Stabilizations* means reviewing a stabilization and report and deciding
whether to stabilize.
* *Standard reviews* refers to reviews for PRs against the repository; these PRs
are not expected to be unduly large or complicated.
* *Prioritized nominations* refers to prioritized lang-team response to
nominated issues, with the expectation that there will be *some* response from
the next weekly triage meeting.
* *Dedicated review* means identifying an individual (or group of individuals)
who will review the changes, as they're expected to require significant
context.
* Other kinds of decisions:
* [Lang team experiments][experiment] are used to add nightly features that
do not yet have an RFC. They are limited to trusted contributors and are
used to resolve design details such that an RFC can be written.
* Compiler [Major Change Proposal (MCP)][mcp] is used to propose a 'larger
than average' change and get feedback from the compiler team.
* Library [API Change Proposal (ACP)][acp] describes a change to the
standard library.

[experiment]: https://lang-team.rust-lang.org/how_to/experiment.html
[mcp]: https://forge.rust-lang.org/compiler/mcp.html
[acp]: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html

## Frequently asked questions

None yet.
Loading
Loading