From 629b283af35b3e7c877fb21217b19d753dbc69d7 Mon Sep 17 00:00:00 2001 From: David Wood Date: Fri, 20 Jun 2025 08:26:50 +0000 Subject: [PATCH 1/2] 2025h2: Arm's goals --- src/2025h2/build-std.md | 166 +++++++++++++++++++++ src/2025h2/rustc-perf-improvements.md | 107 ++++++++++++++ src/2025h2/scalable-vectors.md | 204 ++++++++++++++++++++++++++ 3 files changed, 477 insertions(+) create mode 100644 src/2025h2/build-std.md create mode 100644 src/2025h2/rustc-perf-improvements.md create mode 100644 src/2025h2/scalable-vectors.md diff --git a/src/2025h2/build-std.md b/src/2025h2/build-std.md new file mode 100644 index 00000000..a55fb89c --- /dev/null +++ b/src/2025h2/build-std.md @@ -0,0 +1,166 @@ +# build-std + +| Metadata | | +| :-- | :-- | +| Point of contact | @davidtwco | +| Teams | | +| 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. diff --git a/src/2025h2/rustc-perf-improvements.md b/src/2025h2/rustc-perf-improvements.md new file mode 100644 index 00000000..9b4f6a97 --- /dev/null +++ b/src/2025h2/rustc-perf-improvements.md @@ -0,0 +1,107 @@ +# rustc-perf improvements + +| Metadata | | +| :-- | :-- | +| Point of contact | @Jamesbarford | +| Teams | | +| 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 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. + +... + +### The next 6 months + +... + +### 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. \ No newline at end of file diff --git a/src/2025h2/scalable-vectors.md b/src/2025h2/scalable-vectors.md new file mode 100644 index 00000000..7421438b --- /dev/null +++ b/src/2025h2/scalable-vectors.md @@ -0,0 +1,204 @@ +# SVE and SME on AArch64 + +| Metadata | | +| :-- | :-- | +| Point of contact | @davidtwco | +| Teams | | +| Task owners | | +| Status | Proposed | +| Zulip channel | N/A | +| Tracking issue | [rust-lang/rust-project-goals#270] | + +## Summary + +Over the next six months, we will continue our efforts from the 2025H1 goal to +merge nightly support for SVE and establish a path towards stabilisation: + +- propose language changes which will enable scalable vector types to be + represented in Rust's type system +- land an experimental nightly implementation of SVE +- identify remaining blockers for SVE stabilisation and plan their resolution +- gain a better understanding of SME's implications for Rust and identify first + steps towards design and implementation + +## Motivation + +AArch64 is an important architecture for Rust, with two tier 1 targets and over +thirty targets in lower tiers. It is widely used by some of Rust's largest +stakeholders and as a systems language, it is important that Rust is able to +leverage all of the hardware capabilities provided by the architecture, +including new SIMD extensions: SVE and SME. + +SIMD types and instructions are a crucial element of high-performance Rust +applications and allow for operating on multiple values in a single instruction. +Many processors have SIMD registers of a known fixed length and provide +intrinsics which operate on these registers. Arm's Neon extension is +well-supported by Rust and provides 128-bit registers and a wide range of +intrinsics. + +Instead of releasing more extensions with ever increasing register bit widths, +recent versions of AArch64 have a Scalable Vector Extension (SVE), with vector +registers whose width depends on the CPU implementation and bit-width-agnostic +intrinsics for operating on these registers. By using SVE, code won't need to be +re-written using new architecture extensions with larger registers, new types +and intrinsics, but instead will work on newer processors with different vector +register lengths and performance characteristics. + +SVE has interesting and challenging implications for Rust, introducing value +types with sizes that can only be known at compilation time, requiring +significant work on the language and compiler. Arm has since introduced Scalable +Matrix Extensions (SME), building on SVE to add new capabilities to efficiently +process matrices, with even more interesting implications for Rust. + +Hardware is generally available with SVE, and key Rust stakeholders want to be +able to use these architecture features from Rust. In a recent discussion on +SVE, [Amanieu, co-lead of the library team, said][quote_amanieu]: + +> I've talked with several people in Google, Huawei and Microsoft, all of whom +> have expressed a rather urgent desire for the ability to use SVE intrinsics in +> Rust code, especially now that SVE hardware is generally available. + +While SVE is specifically an AArch64 extension, the infrastructure for scalable +vectors in Rust should also enable Rust to support for RISC-V's "V" Vector +Extension, and this goal will endeavour to extend Rust in an +architecture-agnostic way. SVE is supported in C through Arm's C Language +Extensions (ACLE) but requires a change to the C standard (documented in [pages +122-126 of the 2024Q3 ACLE][acle_sve]), so Rust has an opportunity to be the +first systems programming language with native support for these hardware +capabilities. + +[acle_sve]: https://github.com/ARM-software/acle/releases/download/r2024Q3/acle-2024Q3.pdf +[quote_amanieu]: https://github.com/rust-lang/rust/pull/118917#issuecomment-2202256754 + +### The status quo + +SVE is currently entirely unsupported by Rust, but progress is being made: + +- [rfcs#3268] is open and proposes adding support for scalable vector types to + the language. It has historically been blocked on requiring exceptions in the + type system for these types to be considered `Sized` and act as value types. + [rfcs#3729] addresses these blockers, so this RFC should be able to be + advanced once [rfcs#3729] is ready + - [rust#118917] has an proposed implementation for this relying on + exceptions in the type system until an implementation of [rfcs#3729] is + ready + - It may be possible to land an implementation of this experimentally given + that there is a realistic approach to resolving its implementation + blockers + - [stdarch#1509] is ready to add SVE types and intrinsics once + [rust#118917] has added the infrastructure to support these types +- [rfcs#3729] proposes extending Rust's notion of sizedness to introduce a + hierarchy of sizedness traits and a notion of const and non-const sizedness + which unblocks `extern type`s and scalable vectors being treated as value + types. + - This RFC has had lots of discussion and two design meetings with the + language team. There appears to be some consensus that it's approximately + the right approach to the problem and has been approved for experimentation + in the compiler. + - [rust#137944] was merged implementing the first half of the RFC unstably. It + introduced a hierarchy of sizedness traits, sufficient to unblock + `extern type`s. It will be followed-up with a patch with the const and + non-const sizedness, unblocking scalable vectors. + +[rust#118917]: https://github.com/rust-lang/rust/pull/118917 +[rust#137944]: https://github.com/rust-lang/rust/pull/137944 +[rfcs#3268]: https://github.com/rust-lang/rfcs/pull/3268 +[rfcs#3729]: https://github.com/rust-lang/rfcs/pull/3729 +[stdarch#1509]: https://github.com/rust-lang/stdarch/pull/1509 + +### The next 6 months + +The primary objective of this initial goal is to land a nightly experiment with +SVE, have both RFCs accepted and establish a path towards stabilisation: + +1. Resolve any and all follow-ups to [rust#137944] now that it has been merged +2. Merge a pull request with Part II of [rust#3729]'s implementation +3. Rewrite [rfcs#3268] in light of [rfcs#3729] to defer to [rfcs#3729]'s + solutions for how scalable vectors will fit in the Rust type system +4. Rebase [rust#118917] on top of Part II of the Sized Hierarchy work, enabling + it to be merged experimentally +5. Merge [stdarch#1509] adding SVE types and intrinsics +6. Identify and start addressing remaining stabilisation blockers + +### The "shiny future" we are working towards + +Adding support for Scalable Matrix Extensions in Rust is the next logical step +following SVE support. There are still many unknowns regarding what this will +involve and part of this goal or the next goal will be understanding these +unknowns better. + +## Design axioms + +- **Avoid overfitting.** It's important that whatever extensions to Rust's type + system are proposed are not narrowly tailored to support for SVE/SME, can be + used to support similar extensions from other architectures, and unblocks or + enables other desired Rust features wherever possible and practical. +- **Low-level control.** Rust should be able to leverage the full capabilities + and performance of the underlying hardware features and should strive to avoid + inherent limitations in its support. +- **Rusty-ness.** Extensions to Rust to support these hardware capabilities + should align with Rust's design axioms and feel like natural extensions of the + type system. + +## Ownership and team asks + +Here is a detailed list of the work to be done and who is expected to do it. +This table includes the work to be done by owners and the work to be done by +Rust teams (subject to approval by the team in an RFC/FCP). + +| Task | Owner(s) or team(s) | Notes | +| ---------------------------- | --------------------------------------------- | ---------------------------------------------------------- | +| Discussion and moral support | ![Team][] [lang], [types], [compiler], [libs] | | +| Implementation | @davidtwco | Part II of Sized Hierarchy implementation | +| Dedicated review | ![Team][] [types] | Review Part II of Sized Hierarchy implementation | +| Author RFC | @davidtwco | Re-write [rfcs#3268] in light of [rfcs#3729] | +| Lang team experiments | ![Team][] [libs], [compiler] | Approve experiment of [rfcs#3268] | +| Implementation | @davidtwco | Update [rust#118917] after Part II | +| Standard reviews | ![Team][] [compiler] | Review and approve [rust#118917] | +| Implementation | @davidtwco, ![Team][] [libs] | Update [stdarch#1509] with SVE types/intrinsics | +| Standard reviews | ![Team][] [libs] | Review and approve [stdarch#1509] | +| RFC decisions | ![Team][] [lang] | Language team decide whether to accept [rfcs#3729] | +| RFC decisions | ![Team][] [libs], [compiler] | Compiler/Library team decide whether to accept [rfcs#3268] | + +### 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. \ No newline at end of file From caf21eea8453183c340c909f8c188ce604ab66de Mon Sep 17 00:00:00 2001 From: David Wood Date: Thu, 26 Jun 2025 05:04:42 +0000 Subject: [PATCH 2/2] 2025h2: finish rustc-perf goal description Co-authored-by: James Barford-Evans --- src/2025h2/rustc-perf-improvements.md | 39 ++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 7 deletions(-) diff --git a/src/2025h2/rustc-perf-improvements.md b/src/2025h2/rustc-perf-improvements.md index 9b4f6a97..753afa20 100644 --- a/src/2025h2/rustc-perf-improvements.md +++ b/src/2025h2/rustc-perf-improvements.md @@ -34,16 +34,41 @@ architectures. ### The status quo -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. +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 @@ -104,4 +129,4 @@ Definitions for terms used above: ## Frequently asked questions -None yet. \ No newline at end of file +None yet.