You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a tracking issue for Parallel Rustc Front-end
This feature will improve compilation speed by parallelizing the process of rustc front end (before the codegen which has been parallelized).
The feature was previously called parallel queries (and its tracking issue can be found here), developed by the former parallel rustc working group. Thanks to their work, developers can currently use parallel rustc by setting parallel_compiler=true in config.toml when building the compiler.
The parallel rustc working group has rebooted (here's the associated MCP), which will make parallel front-end the default option in rustc. Here's the (draft) landing strategy for this feature.
Below is the task list.
Solve the problem of single-thread performance reduction
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
The text was updated successfully, but these errors were encountered:
The core crate might be a good benchmark for this. You can immediately build it after rustc and it spends about 10% of its walltime in tokenization/parsing/macro-expansion and ~80% in the query parts. The fraction of codegen is small in comparison.
This is a tracking issue for Parallel Rustc Front-end
This feature will improve compilation speed by parallelizing the process of rustc front end (before the codegen which has been parallelized).
The feature was previously called parallel queries (and its tracking issue can be found here), developed by the former parallel rustc working group. Thanks to their work, developers can currently use parallel rustc by setting
parallel_compiler=true
inconfig.toml
when building the compiler.The parallel rustc working group has rebooted (here's the associated MCP), which will make parallel front-end the default option in rustc. Here's the (draft) landing strategy for this feature.
Below is the task list.
Solve the problem of single-thread performance reduction
DynSend
andDynSync
auto trait for parallel compiler #107586Sharded
an enum and specialize it for the single thread case #114860Sharded
from query state #114894Sharded
and refactorLock
#115388Sharded
only for multiple threads #115162Optimize multi-threading performance
Enable parallel compilation by default in nightly rustc
Bugs or test failures of parallel rustc
tcx
in deadlock handler when parallel compilation #98570evaluate_trait_predicate_recursively
in rustdoc when proving Send/Sync #106930attempted to read from stolen value: rustc_middle::thir::Thir
:-Zthir-unsafeck=yes
#111520CurrentGcx
type to let the deadlock handler accessTyCtxt
#115220ParallelGuard
type to handle unwinding in parallel sections #115144deadlock detected
#111521no ImplicitCtxt stored in tls
#111522value must be in cache after waiting
#111528Resource temporarily unavailable
when limiting max memory #115021assertion failed: found_cycle
#115223Testing
Documentation
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
The text was updated successfully, but these errors were encountered: