# parallel rustc proposal

There seem to be multiple visions of what we should be shooting for when it comes to wg-parallel-rustc. The purpose of this document is to lay out a particular vision and hopefully spark a discussion about it, so that we can all agree on the direction.

## Overriding goals

Some of the core goals that we should be shooting for:

* **Simplicity of design and implementation**
* debugging and reproducing bug reports will be hard enough =)
* Simpler designs often lend themselves to being easier to verify they're correct, and correctness is naturally paramount with rustc
* **No custom rayon**
* the current code uses a fork of rayon, but we wish to remove use of special features
* another option might be a simple threadpool
* **Focus on landing something for everything soon**
* The initial implementation should not be obviously a regression for the common case
* Initially landing parallel compilation can unlock "obviously parallel work" such as parallel codegen which can't progress until infrastructure is in place.
* **Minimizing impact on day-to-day development**
* We shouldn't require all rustc developers to constantly think about threading and possible interleavings, that's just asking for bugs
* **Obviously correct locking schemes**
* We want to avoid granular locks where possible, and instead rely on queries as the sole source of mutable state (a lot of this refactoring has been done)

## Questions to answer

* Q: Should we revert the support for fine-grained parallelism present in the compiler before landing for everyone?

* Niko: We have discussed the idea of being more selective with the places we insert parallelism. For example, just distributing the type-checking of functions across cores, and perhaps other high-level operations like that. This would limit the amount of non-determinism and other stuff that arises but at the cost (presumably) of performance.
* 18 `par_iter`, 7 `parallel!` calls
* These are pretty sporadically spread out through the compiler
* How did we decide to insert these calls at those positions?
* Perhaps not "simple"
* On the other hand, removing seems like maybe a potential for performance regressions
* Dropping seems like a bad idea though (hard to decide what, and not too many cases today)

* Q: What are the conditions for deploying to every user?
* Q: Under what conditions would we revert?
* e.g. are performance regressions in some cases enough?
* e.g. what about a few deadlocks in some cases?
* No need for a specific answer. But we should think at least a little about this.

* Q: How do we decide where parallelism should go?
* Current model appears to be "everywhere we can", loosely
* It would be good to get a read on the current situation from Zoxc
* If we go with rayon, we can probably more readily accept "parallelism everywhere"
* (work stealing and the more advanced executor makes this more viable)

## Specific proposal

* Keep current parallelism scheme, i.e., do not drop any of the existing calls to par_iter/parallel!
* Stop expanding parallelism in the compiler (for now)
* This means that any currently open PRs that add parallelism or try to improve the core infrastructure should not be merged
* possibly with the exception of the jobserver PR (I do not believe it is necessary, so I would hold off there too)
* Land parallelism as the default mode into nightly soon
* We would leave the -Zthreads=4 default
* Document in at least an inside rust blog post that this is happening
* Note that any unexpected hangs or so should definitely be reported
* ask for stacktraces

Presuming no showstopper bugs arise:
* (see question above)
* Let parallel compilation ride into beta/stable
* Start landing further work into nightly once the initial draft hits beta
* This is intended as a way of getting a minimal thing into beta/stable
* hopefully reduces chances of problems arising on stable or beta that are painful to fix
* We can plausibly land gated work before then, but I think it's probably not worth it

* FCP/Design meeting with compiler team to approve this plan