Update date references on parallel-rustc (#1348)

This commit is contained in:
Yuki Okushi 2022-05-09 22:47:50 +09:00 committed by GitHub
parent e4ce969bea
commit 425fa202c8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 13 deletions

View File

@ -1,15 +1,15 @@
# Parallel Compilation
As of <!-- date: 2021-09 --> September 2021, The only stage of the compiler
As of <!-- date: 2022-05 --> May 2022, The only stage of the compiler
that is already parallel is codegen. The nightly compiler implements query evaluation,
but there is still a lot of work to be done. The lack of parallelism at other stages
also represents an opportunity for improving compiler performance. One can try out the current
but there is still a lot of work to be done. The lack of parallelism at other stages
also represents an opportunity for improving compiler performance. One can try out the current
parallel compiler work by enabling it in the `config.toml`.
These next few sections describe where and how parallelism is currently used,
These next few sections describe where and how parallelism is currently used,
and the current status of making parallel compilation the default in `rustc`.
The underlying thread-safe data-structures used in the parallel compiler
The underlying thread-safe data-structures used in the parallel compiler
can be found in the `rustc_data_structures::sync` module. Some of these data structures
use the `parking_lot` crate as well.
@ -23,9 +23,9 @@ There are two underlying thread safe data structures used in code generation:
- `MetadataRef` -> [`OwningRef<Box<dyn Erased + Send + Sync>, [u8]>`][OwningRef]
- This data structure is specific to `rustc`.
During [monomorphization][monomorphization] the compiler splits up all the code to
be generated into smaller chunks called _codegen units_. These are then generated by
independent instances of LLVM running in parallel. At the end, the linker
During [monomorphization][monomorphization] the compiler splits up all the code to
be generated into smaller chunks called _codegen units_. These are then generated by
independent instances of LLVM running in parallel. At the end, the linker
is run to combine all the codegen units together into one binary. This process
occurs in the `rustc_codegen_ssa::base` module.
@ -49,20 +49,20 @@ When a query `foo` is evaluated, the cache table for `foo` is locked.
- If there *is* another query invocation for the same key in progress, we
release the lock, and just block the thread until the other invocation has
computed the result we are waiting for. This cannot deadlock because, as
mentioned before, query invocations form a DAG. Some thread will always make
mentioned before, query invocations form a DAG. Some threads will always make
progress.
## Rustdoc
As of <!-- date: 2021-09--> September 2021, there are still a number of steps
As of <!-- date: 2022-05--> May 2022, there are still a number of steps
to complete before rustdoc rendering can be made parallel. More details on
this issue can be found [here][parallel-rustdoc].
## Current Status
As of <!-- date: 2021-07 --> July 2021, work on explicitly parallelizing the
As of <!-- date: 2022-05 --> May 2022, work on explicitly parallelizing the
compiler has stalled. There is a lot of design and correctness work that needs
to be done.
to be done.
These are the basic ideas in the effort to make `rustc` parallel:
@ -76,7 +76,7 @@ These are the basic ideas in the effort to make `rustc` parallel:
[`rayon`]: https://crates.io/crates/rayon
As of <!-- date: 2021-02 --> February 2021, much of this effort is on hold due
As of <!-- date: 2022-05 --> May 2022, much of this effort is on hold due
to lack of manpower. We have a working prototype with promising performance
gains in many cases. However, there are two blockers: