Stream: t-compiler/wg-parallel-rustc

Topic: testing and binaries from CI


mw (Mar 25 2019 at 15:13, on Zulip):

@Alex Crichton has kindly offered to look into providing CI-generated parallel rustc binaries.

mw (Mar 25 2019 at 15:13, on Zulip):

the plan is to make CI build binaries for Linux, macOs, and Windows and have instructions for downloading them in a convenient way

mw (Mar 25 2019 at 15:15, on Zulip):

as a follow up step, it would be great if we could use those binaries for setting up some external regression testing that compiles a number of projects and checks if the output is the same as the one from the non-parallel compiler.

mw (Mar 25 2019 at 15:16, on Zulip):

(doing this as part of regular CI does not seem to be feasible at the moment)

mw (Mar 25 2019 at 15:16, on Zulip):

cc @Zoxc @nikomatsakis

Alex Crichton (Mar 25 2019 at 15:50, on Zulip):

@mw is there a general tracking issue for parallel queries?

Alex Crichton (Mar 25 2019 at 15:50, on Zulip):

I'm gonna open a tracking issue on rust-lang/rust for this

Wesley Wiser (Mar 25 2019 at 16:13, on Zulip):

@Alex Crichton There's a tacking issue for parallel queries in #48685

Alex Crichton (Mar 25 2019 at 20:53, on Zulip):

Thanks! I've posted a first pass at https://github.com/rust-lang/rust/pull/59417, and we'll see what comes out of that to keep testing

Alex Crichton (Apr 02 2019 at 14:11, on Zulip):

Ok so I had an idea with @nikomatsakis at Rust LATAM which was "what if we just enabled parallel on by default right now?". I was thinking we might not necessarily turn on the actual multithreaded part, but what if we started shipping parallel-capable compilers right now but continued to default the number of threads to 1 while we're working out all the bugs?

Alex Crichton (Apr 02 2019 at 14:11, on Zulip):

I ran a @bors: try build on https://github.com/rust-lang/rust/pull/59417#issuecomment-479013998 and it turns out the slowdown, while there, is quite small at 2-3% across the board.

Alex Crichton (Apr 02 2019 at 14:12, on Zulip):

That seems quite impressive in terms of slowdown, and makes me think that we'd be perfectly suited to enable parallel compilation right now (ok, maybe after the next release on April 11) for testing

Alex Crichton (Apr 02 2019 at 14:12, on Zulip):

that way we won't need any crazy support with try or not, and we can just have normal nightly testing like we have for everything else

Alex Crichton (Apr 02 2019 at 14:12, on Zulip):

@Zoxc and @mw, thoughts?

Cem Karan (Apr 02 2019 at 14:13, on Zulip):

Works for me; it means an extra sip of coffee while the compiler is running. :wink:

Alex Crichton (Apr 02 2019 at 14:25, on Zulip):

Ah this was brought up in the PR but the 2-3% number is actually incorrect, that's number of instructions where the more interesting metric for htis PR is wall time, and wall time regresses by 10% mostly which I think is probably too bad to land in rustc nightly right now

Alex Crichton (Apr 02 2019 at 14:25, on Zulip):

so less actionable than I thought :(

Alex Crichton (Apr 02 2019 at 14:26, on Zulip):

Although honestly the major regressions are all in tiny crates that take 1s extra to compile it looks like

Alex Crichton (Apr 02 2019 at 14:26, on Zulip):

as opposed to larger crates also only regressing by a few seconds, showing up as a large-ish percentage

Alex Crichton (Apr 02 2019 at 14:26, on Zulip):

so perhaps not that bad after all...

Cem Karan (Apr 02 2019 at 14:49, on Zulip):

Do you know what is major cause of the 10% regression? I mean, is it drive access, too much swapping, etc.? If there was an extra flag in rustc/cargo to enable self-profiling and shipping the profiling data back to a central location for further analysis, that could be useful (Apple did something like this when they were switching from the old OS 9/Carbon APIs to the OS X APIs; in their case they were just getting information about the APIs being used by developers, but I can see having a simple way of shipping the profiling data back for analysis being useful here to see what areas need to be concentrated on 'in the wild').

mw (Apr 02 2019 at 14:49, on Zulip):

are there wins too?

Alex Crichton (Apr 02 2019 at 15:03, on Zulip):

@Cem Karan I'm not sure, but I've pigned @Zoxc who may know more

Alex Crichton (Apr 02 2019 at 15:03, on Zulip):

@mw I pinned the number of threads to 1 because it sounds like we're not ready for true parallelism yet

Alex Crichton (Apr 02 2019 at 15:03, on Zulip):

so this was a test of "can we take a small hit to build in parallel mode always and just not use it"

Alex Crichton (Apr 02 2019 at 15:03, on Zulip):

so there were no improvements, only regressions

Alex Crichton (Apr 02 2019 at 15:03, on Zulip):

(as expected though)

mw (Apr 02 2019 at 15:05, on Zulip):

hm, results from here seem to be mixed: https://github.com/rust-lang/rust/pull/59530

Alex Crichton (Apr 02 2019 at 15:43, on Zulip):

@mw oh that's a separate PR with a different strategy (turning on parallel rustc and defaulting threads to num_cpus)

Alex Crichton (Apr 02 2019 at 15:43, on Zulip):

you're looking at wall time as well, right?

Alex Crichton (Apr 02 2019 at 15:43, on Zulip):

it's still got some regressions but overall looks quite good

mw (Apr 03 2019 at 08:28, on Zulip):

Yeah, I was wondering if that was an option: make parallel the default and also letting it take advantage of the parallelism.

mw (Apr 03 2019 at 08:29, on Zulip):

but some of the regressions look quite severe. might be a bad interaction with the jobserver?

Cem Karan (Apr 08 2019 at 15:00, on Zulip):

Cem Karan I'm not sure, but I've pigned Zoxc who may know more

@Zoxc Do you know any more about these regressions? Just curious as to what the cause is...

Zoxc (Apr 08 2019 at 15:03, on Zulip):

Swapping RefCell for parking_lot::Mutex is the main cause. Atomic ops are slower

Cem Karan (Apr 08 2019 at 15:53, on Zulip):

Got it, thanks.

nikomatsakis (Apr 09 2019 at 20:27, on Zulip):

I feel like those percentages... hmm. They are borderline. It may be worth it. It probably depends a bit on how far off we think the actual parallel execution is.

Last update: Nov 17 2019 at 07:50UTC