Skip to content

Commit 7ed324d

Browse files
davidtwcoJamesbarford
davidtwco
and
Jamesbarford
authored
2025h2: SVE + build-std + rustc-perf-improvements (#331)
* 2025h2: Arm's goals * 2025h2: finish rustc-perf goal description Co-authored-by: James Barford-Evans <[email protected]> --------- Co-authored-by: James Barford-Evans <[email protected]>
1 parent a1b8de7 commit 7ed324d

File tree

3 files changed

+502
-0
lines changed

3 files changed

+502
-0
lines changed

‎src/2025h2/build-std.md

Lines changed: 166 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,166 @@
1+
# build-std
2+
3+
| Metadata | |
4+
| :-- | :-- |
5+
| Point of contact | @davidtwco |
6+
| Teams | <!-- TEAMS WITH ASKS --> |
7+
| Task owners | <!-- TASK OWNERS --> |
8+
| Status | Proposed |
9+
| Zulip channel | N/A |
10+
| Tracking issue | [rust-lang/rust-project-goals#274] |
11+
12+
## Summary
13+
14+
Over the next six months, we will continue our efforts to write an RFC for a
15+
minimum viable product (MVP) of build-std which has the potential to be
16+
stabilised once implemented (as opposed to the currently implemented MVP which
17+
is only suitable for experimentation and testing), and then implement it.
18+
19+
## Motivation
20+
21+
build-std is a well-known unstable feature in Cargo which enables Cargo to
22+
re-build the standard library, this is useful for a variety of reasons:
23+
24+
- Building the standard library for targets which do not ship with a
25+
pre-compiled standard library.
26+
- Optimising the standard library for known hardware, such as with non-baseline
27+
target features or options which optimise for code size. This is a common use
28+
case for embedded developers.
29+
- Re-building the standard library with different configuration options (e.g.
30+
changing the optimisation level, using flags which change the ABI, or which
31+
add additional exploit mitigations).
32+
- Re-building the standard library with different `cfg`s (e.g. disabling
33+
`backtrace` in std), to the extent that such configurations are supported by
34+
the standard library.
35+
- Stabilisation of various compiler flags which change the ABI, add additional
36+
exploit mitigations (such as `-Zsanitizers=cfi` or `-Zbranch-protection`), or
37+
which otherwise only make sense to use when the entire program is compiled
38+
with the flag (including std) is blocked on these being unable to be used
39+
properly without being able to rebuild std.
40+
41+
These features are more useful for some subsets of the Rust community, such as
42+
embedded developers where optimising for size can be more important and where
43+
the targets often don't ship with a pre-compiled std.
44+
45+
The fifty-thousand foot view of the work involved in this feature is:
46+
47+
- Having the standard library sources readily available that match the compiler.
48+
- Being able to build those sources without using a nightly toolchain, which has
49+
many possible solutions.
50+
- Having a blessed way to build at least `core` without Cargo, which some users
51+
like Rust for Linux would like.
52+
- This would be optional but may be a side-effect of whatever mechanism for
53+
build-std the MVP RFC eventually proposes.
54+
- Being able to tell the compiler to use the resulting prebuilt standard library
55+
sources instead of the built-in standard library, in a standard way.
56+
- Integrating all of the above into Cargo.
57+
- Making sure all of this works for targets that don't have a pre-built std.
58+
59+
Rust for Linux and some other projects have a requirement to build core
60+
themselves without Cargo (ideally using the same stable compiler they use for
61+
the rest of their project), which is a shared requirement with build-std, as
62+
whatever mechanism these projects end up using could be re-used by the
63+
implementation of build-std and vice-versa.
64+
65+
### The status quo
66+
67+
build-std is currently an unstable feature in Cargo which hasn't seen much
68+
development or progress since its initial development in 2019/2020. There are a
69+
variety of issues in the [wg-cargo-std-aware][wg-cargo-std-aware] repository
70+
which vary from concrete bugs in the current experimental implementation to
71+
vague "investigate and think about this" issues, which make the feature
72+
difficult to make progress on.
73+
74+
Some of the work required for this exists in the current perma-unstable
75+
`-Zbuild-std` implementation, which may be re-used if appropriate.
76+
77+
In 2025H1, the goal owners established a regular sync meeting with liasons from
78+
the library, compiler and Cargo teams which have been successful in creating a
79+
draft RFC that continues to be iterated on and refined before being shared with
80+
the broader project.
81+
82+
[wg-cargo-std-aware]: https://github.com/rust-lang/wg-cargo-std-aware
83+
84+
### The next 6 months
85+
86+
There are two primary objectives of this goal in its first six months:
87+
88+
- Continue to refine and draft a complete RFC for build-std, including a
89+
detailed history of the feature and surrounding discussions going back to its
90+
origins in 2015.
91+
- Next, after and conditional on acceptance of the RFC, proceed with its
92+
implementation.
93+
94+
As part of the goal, the goal owners will regularly be in contact with representatives from
95+
relevant teams in our regular sync call established during the 2025H1 goal period, and will commit
96+
to posting updates on our progress on a monthly basis.
97+
98+
### The "shiny future" we are working towards
99+
100+
After the approval and implementation of the MVP RFC, there will naturally be
101+
follow-up use cases which can be designed and implemented to complete the
102+
build-std feature.
103+
104+
## Design axioms
105+
106+
- Enabling build-std without changing any compilation options or configuration
107+
should produce an equivalent library to that distributed by the project.
108+
- Avoid precluding future extensions to build-std.
109+
- build-std should allow std/alloc/core to be treated more like other
110+
dependencies than currently.
111+
- This represents a general move away from treating std/alloc/core as a
112+
special case.
113+
114+
## Ownership and team asks
115+
116+
| Task | Owner(s) or team(s) | Notes |
117+
| ---------------------------- | ------------------------------------- | ------------------------------------------------------------------- |
118+
| Discussion and moral support | ![Team][] [cargo], [libs], [compiler] | @ehuss, @joshtriplett and @wesleywiser already regularly contribute |
119+
| Author RFC | @davidtwco, @adamgemmell | Continue draft produced in 2025H1 |
120+
| Design meeting | ![Team][] [cargo], [libs], [compiler] | Review initial RFC draft |
121+
| RFC decision | ![Team][] [cargo], [libs], [compiler] | Decide to approve RFC. |
122+
| Implementation | @davidtwco, @adamgemmell | |
123+
| Standard reviews | ![Team][] [cargo], [libs], [compiler] | |
124+
125+
### Definitions
126+
127+
Definitions for terms used above:
128+
129+
* *Discussion and moral support* is the lowest level offering, basically
130+
committing the team to nothing but good vibes and general support for this
131+
endeavor.
132+
* *Author RFC* and *Implementation* means actually writing the code, document,
133+
whatever.
134+
* *Design meeting* means holding a synchronous meeting to review a proposal and
135+
provide feedback (no decision expected).
136+
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
137+
* *Org decisions* means reaching a decision on an organizational or policy
138+
matter.
139+
* *Secondary review* of an RFC means that the team is "tangentially" involved in
140+
the RFC and should be expected to briefly review.
141+
* *Stabilizations* means reviewing a stabilization and report and deciding
142+
whether to stabilize.
143+
* *Standard reviews* refers to reviews for PRs against the repository; these PRs
144+
are not expected to be unduly large or complicated.
145+
* *Prioritized nominations* refers to prioritized lang-team response to
146+
nominated issues, with the expectation that there will be *some* response from
147+
the next weekly triage meeting.
148+
* *Dedicated review* means identifying an individual (or group of individuals)
149+
who will review the changes, as they're expected to require significant
150+
context.
151+
* Other kinds of decisions:
152+
* [Lang team experiments][experiment] are used to add nightly features that
153+
do not yet have an RFC. They are limited to trusted contributors and are
154+
used to resolve design details such that an RFC can be written.
155+
* Compiler [Major Change Proposal (MCP)][mcp] is used to propose a 'larger
156+
than average' change and get feedback from the compiler team.
157+
* Library [API Change Proposal (ACP)][acp] describes a change to the
158+
standard library.
159+
160+
[experiment]: https://lang-team.rust-lang.org/how_to/experiment.html
161+
[mcp]: https://forge.rust-lang.org/compiler/mcp.html
162+
[acp]: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html
163+
164+
## Frequently asked questions
165+
166+
None yet.

‎src/2025h2/rustc-perf-improvements.md

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
# rustc-perf improvements
2+
3+
| Metadata | |
4+
| :-- | :-- |
5+
| Point of contact | @Jamesbarford |
6+
| Teams | <!-- TEAMS WITH ASKS --> |
7+
| Task owners | <!-- TASK OWNERS --> |
8+
| Status | Proposed |
9+
| Zulip channel | [#project-goals/2025h1/rustc-perf-improvements][channel] |
10+
| Tracking issue | [rust-lang/rust-project-goals#275] |
11+
12+
[channel]: https://rust-lang.zulipchat.com/#narrow/channel/478771-project-goals.2F2025h1.2Frustc-perf-improvements
13+
14+
*This goal will be primarily worked on by @Jamesbarford, but @davidtwco or
15+
@Kobzol can always be contacted for updates.*
16+
17+
## Summary
18+
19+
Continue our efforts from 2025H1 to add support to rustc-perf for distributed
20+
benchmarking across multiple platforms and configuration.
21+
22+
## Motivation
23+
24+
Improving the performance of the Rust compiler is a long-standing objective of
25+
the Rust project and compiler team, which has led to the development of the
26+
project's performance tracking infrastructure. While the performance tracking
27+
infrastructure has seen many improvements in recent years, it cannot scale to
28+
support multiple benchmarking machines simultaneously.
29+
30+
There are increasingly demands on the performance infrastructure which require a
31+
more scalable benchmarking infrastructure - benchmarking the parallel compiler
32+
with different thread counts, different codegen backends, or different
33+
architectures.
34+
35+
### The status quo
36+
37+
rustc-perf does not yet support scheduling or accepting benchmarks from
38+
multiple machines.
39+
40+
To ensure ongoing changes don't break existing functionality, tests have
41+
been added to guard the current system. Notable progress includes the
42+
introduction of database tests and incremental improvements to error
43+
handling in the new system.
44+
45+
A new system architecture has been outlined in this
46+
[design document][design_doc] of which progress has commenced in implementing
47+
it. The new system will operate in parallel with the existing one until we
48+
are confident it can fully replace it. rustc-perf does not currently support
49+
scheduling and accepting benchmarks from multiple machines, requiring a
50+
non-trivial rearchitecting to do so. None of our policies around performance
51+
triage and handling regressions currently consider what to do in case of
52+
conflicting benchmarking results.
53+
54+
[design_doc]: https://hackmd.io/wq30YNEIQMSFLWWcWDSI9A
55+
56+
### The next 6 months
57+
58+
This period is a continuation of the previous six months, during which
59+
meaningful progress was made in beginning the implementation of a new system
60+
for rustc-perf.
61+
62+
* Switch the default collector to the new AX-42, initially running on the
63+
legacy non-parallel system.
64+
* Enable benchmarking to run in parallel across multiple collectors.
65+
* Continue expanding test coverage for the new distributed rustc-perf
66+
infrastructure to reduce the risk of future regressions.
67+
* Build a status page to display the health of each collector.
68+
* Add support for benchmarking on AArch64 as a separate architecture.
69+
* Enhance perf.rust-lang.org to display performance data from multiple
70+
collectors, with the ability to compare results within a given configuration
71+
(not across different configurations).
72+
73+
### The "shiny future" we are working towards
74+
75+
Following the completion of this goal, it is anticipated that new platforms and
76+
configurations will be added to rustc-perf, but this is unlikely to warrant
77+
further goals.
78+
79+
## Ownership and team asks
80+
81+
| Task | Owner(s) or team(s) | Notes |
82+
|-----------------------------------------------|------------------------|-------------------------------------------------|
83+
| Discussion and moral support | ![Team][] [infra] | |
84+
| Improve rustc-perf implementation work | @Jamesbarford, @Kobzol | |
85+
| Standard reviews | ![Team][] [infra] | |
86+
| Deploy to production | ![Team][] [infra] | rustc-perf improvements, testing infrastructure |
87+
| Draft performance regression policy | @davidtwco | |
88+
| Policy decision | ![Team][] [compiler] | Update performance regression policy |
89+
| Inside Rust blog post announcing improvements | @Kobzol, @davidtwco | |
90+
91+
### Definitions
92+
93+
Definitions for terms used above:
94+
95+
* *Discussion and moral support* is the lowest level offering, basically
96+
committing the team to nothing but good vibes and general support for this
97+
endeavor.
98+
* *Author RFC* and *Implementation* means actually writing the code, document,
99+
whatever.
100+
* *Design meeting* means holding a synchronous meeting to review a proposal and
101+
provide feedback (no decision expected).
102+
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
103+
* *Org decisions* means reaching a decision on an organizational or policy
104+
matter.
105+
* *Secondary review* of an RFC means that the team is "tangentially" involved in
106+
the RFC and should be expected to briefly review.
107+
* *Stabilizations* means reviewing a stabilization and report and deciding
108+
whether to stabilize.
109+
* *Standard reviews* refers to reviews for PRs against the repository; these PRs
110+
are not expected to be unduly large or complicated.
111+
* *Prioritized nominations* refers to prioritized lang-team response to
112+
nominated issues, with the expectation that there will be *some* response from
113+
the next weekly triage meeting.
114+
* *Dedicated review* means identifying an individual (or group of individuals)
115+
who will review the changes, as they're expected to require significant
116+
context.
117+
* Other kinds of decisions:
118+
* [Lang team experiments][experiment] are used to add nightly features that
119+
do not yet have an RFC. They are limited to trusted contributors and are
120+
used to resolve design details such that an RFC can be written.
121+
* Compiler [Major Change Proposal (MCP)][mcp] is used to propose a 'larger
122+
than average' change and get feedback from the compiler team.
123+
* Library [API Change Proposal (ACP)][acp] describes a change to the
124+
standard library.
125+
126+
[experiment]: https://lang-team.rust-lang.org/how_to/experiment.html
127+
[mcp]: https://forge.rust-lang.org/compiler/mcp.html
128+
[acp]: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html
129+
130+
## Frequently asked questions
131+
132+
None yet.

0 commit comments

Comments
 (0)