---
# System prepended metadata

title: Enable Parallel Rustc Front End In Nightly Builds

---

# Enable Parallel Rustc Front End In Nightly Builds

# Proposal

It has been almost a year since the parallel rustc working group was rebooted. We've made a lot of progress this year and I think it is time to start a public test and promote by enabling the parallel front end in **nightly** versions.

Please let me introduce the current progress and status of this feature, as well as our shipping strategy.

# Current status

### Multiple Threads Performance

Under **8 cores and 8 threads**, the parallel front end can reduce the **clean build** (cargo build with `-Z threads=8` option) time by about **30%** on average. (These crates are from compiler-benchmarks of rustc-perf)

| crate                 | 8cores-master-stage1 | 8cores-8threads-stage1 |         |
| --------------------- | -------------------- | ---------------------- | ------- |
| serde                 | 4.86                 | 2.57                   | -47.12% |
| stm32f4               | 18.89                | 10.97                  | -41.93% |
| diesel                | 17.13                | 10.3                   | -39.87% |
| syn                   | 3.81                 | 2.38                   | -37.53% |
| hyper                 | 11.5                 | 7.41                   | -35.57% |
| regex                 | 4.15                 | 2.77                   | -33.25% |
| clap                  | 4.91                 | 3.3                    | -32.79% |
| unicode-normalization | 1.9                  | 1.3                    | -31.58% |
| serde_derive          | 7.11                 | 4.94                   | -30.52% |
| cranlift-codegen      | 13.57                | 9.47                   | -30.21% |
| core                  | 21.89                | 15.37                  | -29.79% |
| html5ever             | 10.12                | 7.4                    | -26.88% |
| webrender             | 40.60                | 29.85                  | -26.48% |
| image                 | 16.94                | 12.99                  | -23.32% |
| cargo                 | 53.57                | 44.13                  | -17.62% |
| bitmaps               | 1.03                 | 0.85                   | -17.48% |
| libc                  | 1.14                 | 0.95                   | -16.67% |
| exa                   | 9.31                 | 8.12                   | -12.78% |
| ripgrep               | 15.88                | 14.09                  | -11.27% |


[Here](https://perf.rust-lang.org/compare.html?start=cf34adb0dd408d7b2f27a64484df63c36c1cc514&end=9148ca2269d942a02167b2ba918ed9e25467abe8&stat=wall-time&showRawData=true&secondary=false&nonRelevant=true&incrUnchanged=false&incrPatched=false) are the test results from rustc-perf. With 8 threads on the 6-core machine, the wall time on the `full` and `incr-full` scenarios was reduced by 23.29%. There is a 1.87% regression for the `incr-unchanged` and `incr-patched` scenarios, but this should have little impact on users.

### Single Thread Performance

In the past few years, the regression under single thread has always been the blocking of parallel front end. This has also been our focus over the past year. According to the results of rustc-perf, the current regression of parallel front end under single-threaded has been reduced to an average of [1.8%](https://perf.rust-lang.org/compare.html?start=23949593103d03a82c7ebc2e84434ce6c6edc561&end=5a3d3b91048a0adf280e7a4e589c1dda6443f172&stat=wall-time&secondary=false&nonRelevant=true), which is generally an acceptable result.

### Crater Test

A total of 7 regressions occurred in the previous [crater test](https://github.com/rust-lang/rust/pull/115235#issuecomment-1731623939), 5 of which the cause is temporarily unknown, but none of them have been reproduced in the [local test](https://rust-lang.zulipchat.com/#narrow/stream/187679-t-compiler.2Fwg-parallel-rustc/topic/crater.20results/near/393641946). Enabling the parallel front end in the nightly version may help us find more clues.

### UI Tests

All UI test failures caused by enabling parallel front end are fixed. Note that this is only when single-threading is used by default. Diagnostics under multi-threading maybe different with under single-threading, because of order of errors and fatals maybe different.

### Existing Issues

Under multi-threading, compilation will still fail occasionally, such as these [issues](https://github.com/rust-lang/rust/labels/WG-compiler-parallel). This is why the parallel front end still needs to under the `-Z` option. We will gradually address these issues to stabilize this feature.

### Future Improvements

@Zoxc has a [PR](https://github.com/rust-lang/rust/pull/115003) that can improve performance by about 10% on the current basis, but there are still some issues related to rayon that need to be resolved. 

On the other hand, brutally increasing the number of threads and cores (I tried a 48-core machine with 32 threads) did not increase the performance of the parallel front end. This may have a lot to do with the complex dependencies between queries, which leads to frequent data contention that limits performance. In the next year, I will focus on optimizing the current incremental compilation system, and in the process find the key factors and solutions about parallel front end.

# Strategy

For the community and rustc developers, the method to enable the parallel front end is very simple, that is, set the `rustc_parallel` option to `true` in the bootstrap config, then rebuild rustc. Otherwise, it will be turned off. But for general rust developers, it is difficult to switch between serial/parallel rustc.

So here is the plan:

1. Enable the parallel front end in nightly builds, and keep the default number of threads as **1**. Then users can use the parallel rustc front end via **`-Z threads=n`** option(The recommended value is 8).

2. Set it up to serial front end **for beta/stable** builds via bootstrap. 

3. Switch over the **alt builders** from parallel rustc to serial, so we have artifacts without parallel to test against the artifacts with parallel.

4. Observe and get user feedback. Including: 

   (1) When the number of threads is 1, will the parallel front end cause bugs/regressions?

   (2) What will the experience be like with `-Z threads=n` option?
   
5. Fix the known issues/deadlocks with multiple threads, actively looking for possible new issues and fix them too.

6. When we ensure the stablization of parallel front end , enable and stablize it on beta/stable builds.

   


# Mentors or Reviewers

@oli-obk @cjgillot @nnethercote @bjorn3 @Kobzol 

# Process

The main points of the [Major Change Process][MCP] are as follows:

* [x] File an issue describing the proposal.
* [ ] A compiler team member or contributor who is knowledgeable in the area can **second** by writing `@rustbot second`.
    * Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a `-C flag`, then full team check-off is required.
    * Compiler team members can initiate a check-off via `@rfcbot fcp merge` on either the MCP or the PR.
* [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered **approved**.

You can read [more about Major Change Proposals on forge][MCP].

[MCP]: https://forge.rust-lang.org/compiler/mcp.html

# Comments

**This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.**