Promoting Parallel Front End - Rust Project Goals (original) (raw)

Summary

Continue to parallelize front-end stabilization and performance improvements, continuing from the 2024h2 goal.

Motivation

There are still some occasional deadlock issues, and in environments with high thread counts (>16) performance may be reduced due to data races.

The status quo

Many current issues reflect ICE or deadlock problems that occur during the use of parallel front end. We need to resolve these issues to enhance its robustness. We also need theoretical algorithms to detect potential deadlocks in query systems.

The current parallel front end still has room for further improvement in compilation performance, such as parallelization of HIR lowering and macro expansion, and reduction of data contention under more threads (>= 16).

We can use parallel front end in bootstrap to alleviate the problem of slow build of the whole project.

Cargo does not provide an option to enable the use of parallel front end, so it can only be enabled by passing rustc options manually.

The next 6 months

The "shiny future" we are working towards

We need a detection algorithm to theoretically prove that the current query system and query execution process do not bring potential deadlock problems.

The existing rayon library implementation is difficult to fundamentally eliminate the deadlock problem, so we may need a better scheduling design to eliminate deadlock without affecting performance.

The current compilation process with GlobalContext as the core of data storage is not very friendly to parallel front end. Maybe try to reduce the granularity (such as modules) to reduce data competition under more threads and improve performance.

Design axioms

The parallel front end should be:

Ownership and team asks

Owner: Sparrow Li and Parallel Rustc WG own this goal

Frequently asked questions