2018.11.16

The topic of today’s steering meeting was future planning. Specifically, we were looking at some of the ideas we’ve had for major initiatives and trying to drill into them and make them more concrete. You can read the full thread over on Zulip.

We began by observing that the ultimate decisions we make here will be very influenced by the number of leaders we can find, and what they want to do, and ultimately decided to focus first on the technical angle before thinking about what leaders we have etc.

We made an initial breakdown of the work to be done into some big areas, which was later amended with a few more areas:

• parallelize with many threads
• improving “batch compilation”:
  • do what we do now, but better:
    • type-check faster, trait checking, etc
    • optimize MIR and generate better LLVM
    • do things better in the backend / improve ThinLTO (link)
    • avoid things like dsymutil
    • need to look at “time breakdown” across projects a bit perhaps?
  • defer, coallesce, and avoid work
    • multi-crate compilation model
    • MIR-only rlibs, which helps identify duplicates as well as dead code
    • “polymorphization” to coallesce monomorphized instances that have the same code
  • distribute and cache work across machines
• improving RLS experience:
  • end-to-end queries
  • incrementalization
  • …
• “UX” improvements
  • continue compiling even when errors occur, particularly getting through to the borrow check phase (link)
  • error-message work
  • …

For the rest of this conversation, though, we focused on batch compilation. We discussed opportunities for getting estimates of the effectiveness of some of these ideas:

• for MIR-only rlibs, mw already did some of that work. There is great potential, but we need effective parallelization.
• thanks to hard work by Zoxc, mw, and others, we have a prototype parallel implementation, so mw volunteered to gather some data
• for polymorphization, we can of course use LLVM’s mergefunc to get some idea, but it seems likely that we can find more opportunities than LLVM does, and of course we would also operate earlier so the impact is larger. We would begin by doing an analysis over MIR – this would be a great place for someone who wants to work on a more weighty project to get involved.
  • one concern is that debuginfo and polymorphization may be tricky to combine
• in principle we should be able to see, for large projects, how much code we wind up using in the end from dependencies, which might give us wins if we can defer that work through multi-crate compilation

One question mark that was raised was how important it is to extend the query system further into the front-end of the compiler – that code is currently usually pretty fast relative to compilation as a whole. However, if we want to really transform the RLS experience, we clearly need great progress here. So to some extent this may come down to the relative importance of RLS vs batch compilation. Ultimately, the consensus was that we need to measure and get a clear idea where we are spending our time (shocker).

A lot of these topics we’ve discussed above will require major architectural overhauls to the compiler, so one thing we discussed was the desire to sketch out those refactorings and the dependencies between them into a kind of chart. We also talked about the need to “pay down” technical debt through cleanup refactorings, and how those refactorings should be given high priority. Finally, we talked some about how the rustc crate graph could stand for some reorganization – this perhaps falls under technical debt. =)

(Fun fact: we initially split rustc into crates not for compilation time but rather because – shortly before 1.0 – the memory usage for compiling and linking the rustc crate was exceeding 4GB, preventing us from issuing builds on 32 bit machines.)

Action items

We enumerated some goals to try and get done before the next steering meeting. If you’d like to help with one of these tasks, let nikomatsakis know!

• take another stab at collecting and organizing ideas, incorporating ideas around UX in particular, but also breaking out RLS from batch compilation (nikomatsakis)
• gather statistics about where we spend our time from perf and perhaps elsewhere (?)
• draw up a proposal for polymorphization analysis / strategy (maybe nikomatsakis?)
• collecting some numbers on how parallel queries performs these days (mw)
• draw the graph of refactor dependencies (eddyb/nikomatsakis, perhaps?)