Stream: t-compiler/wg-parallel-rustc

Topic: sync 2019.04.10


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

BTW, @mw and I were talking about trying to sync up tomorrow (2019.04.10) at 10am UTC-04:00 a bit just to kind of sketch out a "roadmap" for parallel compilation. But maybe it makes more sense to schedule that meeting more actively, so that e.g. @Zoxc can attend? I'm interested in trying to get a better feeling for the steps and requirements here -- specifically not just looking at coding, but also at testing and the like. I'm specifically interested in trying to recruit some folks to help drive the process forward and relieve @Zoxc a bit (I think @mw is overburdened), and I'd like to get a better idea what we think those people would have to do.

mw (Apr 10 2019 at 13:31, on Zulip):

posting some things here for reference:

mw (Apr 10 2019 at 13:32, on Zulip):

@Zoxc did a recent test of the parallel compiler on perf.rlo: https://github.com/rust-lang/rust/pull/59530

mw (Apr 10 2019 at 13:33, on Zulip):

these are the numbers with 8 threads and jobserver integration disabled: https://perf.rust-lang.org/compare.html?start=7641873f591dca86e2b31f60fc76b39553892631&end=eafa54e32a3ec69221700503f21cb456de859f9e&stat=wall-time

mw (Apr 10 2019 at 13:34, on Zulip):

these are the numbers with 8 threads and jobserver integration enabled: https://perf.rust-lang.org/compare.html?start=2002b4b39a16760f37107cf02d7a91ff316d3073&end=e1f9d0488d052f77315c033b3b8bf47a4d8fdb11&stat=wall-time

mw (Apr 10 2019 at 13:34, on Zulip):

(correct me if I'm wrong)

mw (Apr 10 2019 at 13:35, on Zulip):

jobserver integration seems to have some problems still, as some crates show bad regressions

mw (Apr 10 2019 at 13:36, on Zulip):

I don't know if we have numbers for 1 thread anywhere

mw (Apr 10 2019 at 13:37, on Zulip):

although here are some numbers from local test runs that @Zoxc did (which include the 1 thread case):

mw (Apr 10 2019 at 13:37, on Zulip):

./x.py build: https://github.com/rust-lang/rust/pull/59530#issuecomment-481557551

mw (Apr 10 2019 at 13:37, on Zulip):

./x.py check: https://github.com/rust-lang/rust/pull/59530#issuecomment-481562350

nikomatsakis (Apr 10 2019 at 13:44, on Zulip):

Great-- @mw btw I might be ~10-15 minutes late (but maybe not)

nikomatsakis (Apr 10 2019 at 13:44, on Zulip):

I'm running a bit behind today but I'm going to try and get into the office

Zoxc (Apr 10 2019 at 13:47, on Zulip):

https://github.com/rust-lang/rust/pull/59804 fixes the jobserver regression

Zoxc (Apr 10 2019 at 13:48, on Zulip):

Those local times are with that fix applied

mw (Apr 10 2019 at 13:51, on Zulip):

That's great to hear, @Zoxc!

mw (Apr 10 2019 at 13:52, on Zulip):

So this would be perf.rlo numbers with 8 threads and the fix: https://perf.rust-lang.org/compare.html?start=e1f9d0488d052f77315c033b3b8bf47a4d8fdb11&end=29efa193a1a6b5480ece517b29cc2a2ad035aa25&stat=wall-time ?

mw (Apr 10 2019 at 13:52, on Zulip):

or this? https://perf.rust-lang.org/compare.html?start=3750348daff89741e3153e0e120aa70a45ff5b68&end=29efa193a1a6b5480ece517b29cc2a2ad035aa25&stat=wall-time

mw (Apr 10 2019 at 13:53, on Zulip):

yeah, the second one should the comparison against master

mw (Apr 10 2019 at 14:05, on Zulip):

@Zoxc, we don't have a complete perf.rlo run for 1 thread with the fix applied, do we?

Zoxc (Apr 10 2019 at 14:07, on Zulip):

No. We can do one to see if it triggered, but it may not have

mw (Apr 10 2019 at 14:07, on Zulip):

What do you mean by "triggered"?

Zoxc (Apr 10 2019 at 14:09, on Zulip):

As in affected performance when using 1 thread

Zoxc (Apr 10 2019 at 14:09, on Zulip):

https://github.com/rust-lang/rust/pull/59693 should be helpful too for perf, as it avoids lots of locks

nikomatsakis (Apr 10 2019 at 14:13, on Zulip):

(I'm here now)

nikomatsakis (Apr 10 2019 at 14:13, on Zulip):

catching up

mw (Apr 10 2019 at 14:13, on Zulip):

alright

nikomatsakis (Apr 10 2019 at 14:14, on Zulip):

maybe we should start by establishing our goals :)

nikomatsakis (Apr 10 2019 at 14:14, on Zulip):

i.e., for this discussion

mw (Apr 10 2019 at 14:14, on Zulip):

I think the main question I'm interested in is: How can we make parallel the default asap, in a responsible way

nikomatsakis (Apr 10 2019 at 14:15, on Zulip):

yes, that sounds good, and to dig a bit deeper in

nikomatsakis (Apr 10 2019 at 14:15, on Zulip):

what are some of the milestones along that way

nikomatsakis (Apr 10 2019 at 14:15, on Zulip):

what kind of testing do we think we need

mw (Apr 10 2019 at 14:16, on Zulip):

so one approach would be to just switch it on for nightly in the next cycle, if the expected regressions are not too big

mw (Apr 10 2019 at 14:16, on Zulip):

and if there are no other blockers

mw (Apr 10 2019 at 14:16, on Zulip):

that would get us some testing via the standard test suite

mw (Apr 10 2019 at 14:16, on Zulip):

and lots of in the field testing

nikomatsakis (Apr 10 2019 at 14:16, on Zulip):

ok so let's as the question that @Alex Crichton was asking:

Can we enable the infrastructure but only use one thread?

nikomatsakis (Apr 10 2019 at 14:17, on Zulip):

Or would we rather just do it with parallelism

nikomatsakis (Apr 10 2019 at 14:17, on Zulip):

I guess the concerns are two-fold:

mw (Apr 10 2019 at 14:17, on Zulip):

if the jobserver works, I think it would be better to do with N threads

nikomatsakis (Apr 10 2019 at 14:17, on Zulip):

I think if we are going to enable it with parallelism, that's a good idea, but we should trumpet it, and try to make it an official feedback period

Zoxc (Apr 10 2019 at 14:17, on Zulip):

I'd say do it with parallelism, just 1 thread won't give us anything useful

mw (Apr 10 2019 at 14:17, on Zulip):

so we get more correctness testing

nikomatsakis (Apr 10 2019 at 14:17, on Zulip):

e.g. I imagine something like this

nikomatsakis (Apr 10 2019 at 14:17, on Zulip):

we turn it on just after beta is cut

nikomatsakis (Apr 10 2019 at 14:17, on Zulip):

we post a blog post

nikomatsakis (Apr 10 2019 at 14:18, on Zulip):

we encourage people to try it out for 3 weeks

nikomatsakis (Apr 10 2019 at 14:18, on Zulip):

reporting bugs, etc

nikomatsakis (Apr 10 2019 at 14:18, on Zulip):

and then at the end of those 3 weeks, we have some criteria that we can use to decide if we want to just leave it on

nikomatsakis (Apr 10 2019 at 14:18, on Zulip):

I think it woul be something like this: no correctness bugs (that we don't have a fix for), no perf regression of >N%?

mw (Apr 10 2019 at 14:19, on Zulip):

one question: would people have a way to opt out?

mw (Apr 10 2019 at 14:19, on Zulip):

other than sticking to an older nightly

nikomatsakis (Apr 10 2019 at 14:19, on Zulip):

I would presume they could use some env var to fix to 1 thread

nikomatsakis (Apr 10 2019 at 14:19, on Zulip):

but that's a good point

nikomatsakis (Apr 10 2019 at 14:20, on Zulip):

we definitely want some way to opt out

nikomatsakis (Apr 10 2019 at 14:20, on Zulip):

(in case of horrible bugs)

nikomatsakis (Apr 10 2019 at 14:20, on Zulip):

Do we think we would need a stronger opt out that 1 thread?

mw (Apr 10 2019 at 14:20, on Zulip):

switching to 1 thread is a semi-opt-out :)

Zoxc (Apr 10 2019 at 14:20, on Zulip):

-Z thread=1 should pretty much catch all horrible bugs

nikomatsakis (Apr 10 2019 at 14:20, on Zulip):

Yeah, I know. But I think it's strong enough, unless you have an argument why it wouldn't be

nikomatsakis (Apr 10 2019 at 14:20, on Zulip):

I mean there is always the "old nightly" opt out

mw (Apr 10 2019 at 14:21, on Zulip):

we do have the option to switch back to non-parallel quickly if there is something horrible not fixed by 1 thread

Alex Crichton (Apr 10 2019 at 14:21, on Zulip):

FWIW my thinking was to roll this out gradually so roll out a default of -Z threads=1 first on nightly, and only after that goes well switch the defaults to parallel-by-default

Alex Crichton (Apr 10 2019 at 14:21, on Zulip):

I was thinking we wouldn't want to roll out parallel-by-default all of a sudden (even if we're confident in it)

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

So there is an alternative

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

which is that we roll out with a default of 1 thread, and we encourage people to opt in to parallelism

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

That's the more conservative approach

Alex Crichton (Apr 10 2019 at 14:22, on Zulip):

right yeah, and that'd give a brief period for the more intrepid to give feedback

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

The downside is that people pay the price for parallel support

mw (Apr 10 2019 at 14:22, on Zulip):

sounds good too

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

But the upside is that we don't break anyone

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

and we can still trumpet it

Alex Crichton (Apr 10 2019 at 14:22, on Zulip):

I was hoping that the price of parallel support would be pretty small

nikomatsakis (Apr 10 2019 at 14:22, on Zulip):

i.e., so they know why they are paying that price

mw (Apr 10 2019 at 14:22, on Zulip):

yes, the new default would be slower

Alex Crichton (Apr 10 2019 at 14:23, on Zulip):

if it's like 2-3% slower I think that's fine b/c we'd quickly recover it later

Alex Crichton (Apr 10 2019 at 14:23, on Zulip):

but measurements were showing up to 20% slower

Alex Crichton (Apr 10 2019 at 14:23, on Zulip):

and 10% for bigger crates

Alex Crichton (Apr 10 2019 at 14:23, on Zulip):

although I think @Zoxc you were looking into some ways to make those areas faster?

Alex Crichton (Apr 10 2019 at 14:23, on Zulip):

@nikomatsakis by trumpet do you mean like an internals post or more broad?

nikomatsakis (Apr 10 2019 at 14:23, on Zulip):

Basically there are three options:

nikomatsakis (Apr 10 2019 at 14:23, on Zulip):

I think the middle 2 are obviously better

Zoxc (Apr 10 2019 at 14:24, on Zulip):

@Alex Crichton There's 2 PR open that might help. I'll open another too

nikomatsakis (Apr 10 2019 at 14:24, on Zulip):

nikomatsakis by trumpet do you mean like an internals post or more broad?

not clear, at minimum an internals post

Alex Crichton (Apr 10 2019 at 14:24, on Zulip):

kk, makes sense, agreed that being loud is good here

nikomatsakis (Apr 10 2019 at 14:24, on Zulip):

I feel like it wouldn't be out of the question to write a blog.rust-lang.org post

nikomatsakis (Apr 10 2019 at 14:24, on Zulip):

this is a pretty big deal imo

Alex Crichton (Apr 10 2019 at 14:24, on Zulip):

I'd save that for "parallel is on by default"

nikomatsakis (Apr 10 2019 at 14:24, on Zulip):

personally, I don't see why we can't write two posts :)

mw (Apr 10 2019 at 14:24, on Zulip):

yeah

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

lol true

nikomatsakis (Apr 10 2019 at 14:25, on Zulip):

maybe a short one now like:

Parallel experimentation period!

then another one like

Parllel on by default!

nikomatsakis (Apr 10 2019 at 14:25, on Zulip):

the latter would have more numbers etc

nikomatsakis (Apr 10 2019 at 14:25, on Zulip):

We probably want to be a bit careful in our framing

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

I have nothing against that :)

nikomatsakis (Apr 10 2019 at 14:25, on Zulip):

i.e., maybe we say that we expect to turn it off again

nikomatsakis (Apr 10 2019 at 14:25, on Zulip):

so it's more like "check out what's coming"

mw (Apr 10 2019 at 14:25, on Zulip):

sounds acceptable to me

nikomatsakis (Apr 10 2019 at 14:25, on Zulip):

basically I think we should be clear that it is not a failure if we find a bunch of bugs and turn it off :)

nikomatsakis (Apr 10 2019 at 14:26, on Zulip):

but just "progress"

nikomatsakis (Apr 10 2019 at 14:26, on Zulip):

anyway, we can discuss with core team tongiht, @Alex Crichton, re: blog post vs internals

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

oh no debate from me, I'd consider either fine

nikomatsakis (Apr 10 2019 at 14:26, on Zulip):

I just happen to think (a) we underuse the blog and (b) we need people to know about compile time progress

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

agreed :)

nikomatsakis (Apr 10 2019 at 14:27, on Zulip):

so, when would we want to target this? the next release is very soon (this week?)

nikomatsakis (Apr 10 2019 at 14:27, on Zulip):

this conversation is turning out a bit differently than I expected

nikomatsakis (Apr 10 2019 at 14:27, on Zulip):

so let me ask a different question

Alex Crichton (Apr 10 2019 at 14:27, on Zulip):

so, when would we want to target this? the next release is very soon (this week?)

Alex Crichton (Apr 10 2019 at 14:27, on Zulip):

tomorrow!

nikomatsakis (Apr 10 2019 at 14:27, on Zulip):

what are the dependencies we feel we need to do this middle path

nikomatsakis (Apr 10 2019 at 14:28, on Zulip):

obviously there were some PRs that have to land

nikomatsakis (Apr 10 2019 at 14:28, on Zulip):

@Zoxc -- you would know best, are there still known performance cases that are (say) >20% perf loss?

nikomatsakis (Apr 10 2019 at 14:28, on Zulip):

(once those PRs land)

Alex Crichton (Apr 10 2019 at 14:28, on Zulip):

It sounded like @Zoxc had a few PRs to speed up those cases

Alex Crichton (Apr 10 2019 at 14:28, on Zulip):

and I'd imagine we'd profile afterwards to see the impact and evaluate which strategy to take

Zoxc (Apr 10 2019 at 14:29, on Zulip):

I don't know the impact of the PRs yet

nikomatsakis (Apr 10 2019 at 14:29, on Zulip):

so maybe we should set some thresholds

Zoxc (Apr 10 2019 at 14:29, on Zulip):

If we start with thread=1, when will we escalate to multiple threads?

nikomatsakis (Apr 10 2019 at 14:29, on Zulip):

and basically we try to do this on the next release after those thresholds are met?

mw (Apr 10 2019 at 14:29, on Zulip):

another question: would this affect other users of librustc much (rustdoc, RLS, etc)

Alex Crichton (Apr 10 2019 at 14:30, on Zulip):

I would naively propose that if a big crate regresses more than 5% we shouldn't release it

Alex Crichton (Apr 10 2019 at 14:30, on Zulip):

but little crates regressing 10-20% is fine

mw (Apr 10 2019 at 14:30, on Zulip):

sounds reasonable

nikomatsakis (Apr 10 2019 at 14:31, on Zulip):

Another way to put it would be something like: regressions are ok if they are <5% OR <.1 sec or something

nikomatsakis (Apr 10 2019 at 14:31, on Zulip):

(so it is independent of crate size)

Alex Crichton (Apr 10 2019 at 14:31, on Zulip):

seems reasonable to me

Alex Crichton (Apr 10 2019 at 14:32, on Zulip):

everything should be <5% or <5s

nikomatsakis (Apr 10 2019 at 14:32, on Zulip):

If we start with thread=1, when will we escalate to multiple threads?

good question -- I think this is something we would want to cover in the blog post too. i.e., what is the overall rollout plan?

nikomatsakis (Apr 10 2019 at 14:32, on Zulip):

I imagine we'd go through the stages one release at a time

Alex Crichton (Apr 10 2019 at 14:32, on Zulip):

I would naively propose "a week with no major issues"

nikomatsakis (Apr 10 2019 at 14:32, on Zulip):

presuming no show stopper problems

Alex Crichton (Apr 10 2019 at 14:32, on Zulip):

oh I don't think we need to wait a whole cycle

nikomatsakis (Apr 10 2019 at 14:32, on Zulip):

I would naively propose "a week with no major issues"

or that ;) much more aggressive than me

Alex Crichton (Apr 10 2019 at 14:32, on Zulip):

we just want to give people time to test

Alex Crichton (Apr 10 2019 at 14:33, on Zulip):

in the sense that the purpose of "parallel capable but default not parallel" is basically asking everyone to do testing and report back

Alex Crichton (Apr 10 2019 at 14:33, on Zulip):

(aka on some internals thread)

nikomatsakis (Apr 10 2019 at 14:33, on Zulip):

1 week seems aggressive -- maybe 2 weeks? but this is a minor point. The main thing is that you imagine going from "enabled but with 1 thread" to "enabled by default" within 1 release cycle

Alex Crichton (Apr 10 2019 at 14:33, on Zulip):

barring anything major coming up yeah

nikomatsakis (Apr 10 2019 at 14:34, on Zulip):

I .. think I like it. "Anything major" being either correctness problems or perf regressions that meet those critera we outlined above?

Alex Crichton (Apr 10 2019 at 14:34, on Zulip):

yeah

Alex Crichton (Apr 10 2019 at 14:34, on Zulip):

as a general "if we feel like there's too much outcry we probably shoudln't enable it"

Alex Crichton (Apr 10 2019 at 14:34, on Zulip):

"or if our thresholds aren't met we won't enable it"

Alex Crichton (Apr 10 2019 at 14:34, on Zulip):

although I do think we should shoot for an almost universal win for parallel actually enabled by default

nikomatsakis (Apr 10 2019 at 14:35, on Zulip):

as a general "if we feel like there's too much outcry we probably shoudln't enable it"

right, ultimately it comes down to this, but I'm trying to do a bit better

Alex Crichton (Apr 10 2019 at 14:35, on Zulip):

the "<5% or <5s" threshold I was thinking was only for "parallel capable, single threaded"

nikomatsakis (Apr 10 2019 at 14:35, on Zulip):

even if we don't publicize those thresholds :)

nikomatsakis (Apr 10 2019 at 14:35, on Zulip):

but often it's kind of hard to judge

Alex Crichton (Apr 10 2019 at 14:35, on Zulip):

lol good point

Alex Crichton (Apr 10 2019 at 14:35, on Zulip):

3 weeks of people satisfied there's no major correctness bugs or major regressions?

nikomatsakis (Apr 10 2019 at 14:36, on Zulip):

yes, I feel good about that

mw (Apr 10 2019 at 14:36, on Zulip):

3 weeks and then we would test default to N threads?

Alex Crichton (Apr 10 2019 at 14:36, on Zulip):

major correctness bug being "requires more than 100 loc to fix" and major regressions being ">5% runtime with parallel enabled"

nikomatsakis (Apr 10 2019 at 14:36, on Zulip):

3 weeks of people satisfied there's no major correctness bugs or major regressions?

actually maybe it's even too long

nikomatsakis (Apr 10 2019 at 14:36, on Zulip):

maybe 2 weeks is better, since that then gives us 2 weeks of testing with N>1

Alex Crichton (Apr 10 2019 at 14:36, on Zulip):

3 hours of people satisfied!

Alex Crichton (Apr 10 2019 at 14:36, on Zulip):

2 sgtm

nikomatsakis (Apr 10 2019 at 14:36, on Zulip):

and then 2 weeks for being sloppy :P

mw (Apr 10 2019 at 14:37, on Zulip):

ok, this sounds all good, but :)

nikomatsakis (Apr 10 2019 at 14:37, on Zulip):

(in all seriousness the week of the release I'd prefer to have nothing left to do, so we get 1 week to either pull it out, or write a triumphant blog post)

nikomatsakis (Apr 10 2019 at 14:37, on Zulip):

Hold on, before the concern, let's lay out the schedule to be clear

mw (Apr 10 2019 at 14:37, on Zulip):

I want to make sure we have the bandwidth to do this

nikomatsakis (Apr 10 2019 at 14:37, on Zulip):

Yes, I want to come to that

nikomatsakis (Apr 10 2019 at 14:37, on Zulip):

But first I want to be sure we're all on same page on what we said so far

mw (Apr 10 2019 at 14:37, on Zulip):

:+1:

Alex Crichton (Apr 10 2019 at 14:39, on Zulip):

(I don't mind giving this a stab to lay it out, I don't see anyone else typing and I'm not sure if I should be able to)

nikomatsakis (Apr 10 2019 at 14:39, on Zulip):
nikomatsakis (Apr 10 2019 at 14:39, on Zulip):

(I don't mind giving this a stab to lay it out, I don't see anyone else typing and I'm not sure if I should be able to)

I think you can't in the group channels :)

mw (Apr 10 2019 at 14:40, on Zulip):

I think you can't in the group channels :)

A distracting feature anyway :)

Alex Crichton (Apr 10 2019 at 14:40, on Zulip):

that timeline assumes 1 week (ish) to get to the point we're ready to enable parallel capable compilers by default, right?

mw (Apr 10 2019 at 14:40, on Zulip):

so does that mean that the next cycle is out of the question?

nikomatsakis (Apr 10 2019 at 14:40, on Zulip):

I don't quite know what you mean

nikomatsakis (Apr 10 2019 at 14:41, on Zulip):

so does that mean that the next cycle is out of the question?

I think it is, but I think 6 weeks from now is plausible

Alex Crichton (Apr 10 2019 at 14:41, on Zulip):

you said in 5 weeks, a week before the 1.35 release, we'd have a big blog post

Alex Crichton (Apr 10 2019 at 14:41, on Zulip):

but 4 weeks backwards is one week from now

mw (Apr 10 2019 at 14:41, on Zulip):

because I'll be on parental leave June and July, meaning I wouldn't be available much

Alex Crichton (Apr 10 2019 at 14:41, on Zulip):

so we have the next week to get ready to ship a parallel compiler

Alex Crichton (Apr 10 2019 at 14:41, on Zulip):

then 2 weeks to test it

Alex Crichton (Apr 10 2019 at 14:41, on Zulip):

then 2 weeks to test parallel-by-default

nikomatsakis (Apr 10 2019 at 14:41, on Zulip):

I did not intend to start with the upcoming release

nikomatsakis (Apr 10 2019 at 14:42, on Zulip):

because we still have pending PRs etc

nikomatsakis (Apr 10 2019 at 14:42, on Zulip):

but I guess we should talk about that

nikomatsakis (Apr 10 2019 at 14:42, on Zulip):

because I'll be on parental leave June and July, meaning I wouldn't be available much

e.g., this

nikomatsakis (Apr 10 2019 at 14:42, on Zulip):

also I know I personally will be in Greece from mid July - mid August, and then there is rustconf etc

mw (Apr 10 2019 at 14:42, on Zulip):

of course I don't insist that this should wait for me being there

Zoxc (Apr 10 2019 at 14:42, on Zulip):

We can test thread=1 this cycle and >1 next too

Alex Crichton (Apr 10 2019 at 14:43, on Zulip):

so nightly becomes 1.36 tomorrow (ish)

Alex Crichton (Apr 10 2019 at 14:43, on Zulip):

nightly becomes 1.37 on may 23

Alex Crichton (Apr 10 2019 at 14:43, on Zulip):

1.38 on june 4

Alex Crichton (Apr 10 2019 at 14:43, on Zulip):

er, july 4

nikomatsakis (Apr 10 2019 at 14:44, on Zulip):

right, so per the plan I outlined, we either start with threads=1 next week or something, or else on may 23. I was imagining starting Friday, May 24, which would put the 2 week point around Friday, June 7

Alex Crichton (Apr 10 2019 at 14:44, on Zulip):

ok so a parallel-by-default compiler on June July 4 reaches beta?

Alex Crichton (Apr 10 2019 at 14:44, on Zulip):

where the 1.37 release will have a parallel-by-default compiler?

nikomatsakis (Apr 10 2019 at 14:45, on Zulip):

ok so a parallel-by-default compiler on June 4 reaches beta?

do you mean July 4

Alex Crichton (Apr 10 2019 at 14:45, on Zulip):

er yes

nikomatsakis (Apr 10 2019 at 14:45, on Zulip):

that was what I had in mind

Alex Crichton (Apr 10 2019 at 14:45, on Zulip):

ok so we have until July 4 to enable parallel by defaulting, giving us 12 weeks of runway

nikomatsakis (Apr 10 2019 at 14:45, on Zulip):

I guess that means that it will hit stable in .. August 8?

Alex Crichton (Apr 10 2019 at 14:45, on Zulip):

(from today)

nikomatsakis (Apr 10 2019 at 14:46, on Zulip):

right before RustConf :)

Alex Crichton (Apr 10 2019 at 14:46, on Zulip):

August 15

nikomatsakis (Apr 10 2019 at 14:46, on Zulip):

assuming all goes well, of course

mw (Apr 10 2019 at 14:46, on Zulip):

wait, I don't understand

nikomatsakis (Apr 10 2019 at 14:46, on Zulip):

ok, Aug 15

mw (Apr 10 2019 at 14:46, on Zulip):

when would be the testing cycle?

Alex Crichton (Apr 10 2019 at 14:47, on Zulip):

Roughly speaking (not using the 2 weeks niko mentioned above which we could still do of course) the next 6 weeks are "test a threads=1 compiler" and the next 6 weeks is "test a threads=N compiler"

Alex Crichton (Apr 10 2019 at 14:47, on Zulip):

were that's what we're releasing as nightlies

Alex Crichton (Apr 10 2019 at 14:47, on Zulip):

and that brings us to July 4

mw (Apr 10 2019 at 14:47, on Zulip):

ok

mw (Apr 10 2019 at 14:48, on Zulip):

i.e. try to land the pending optimizations and then switch nightly

mw (Apr 10 2019 at 14:48, on Zulip):

to 1 thread?

nikomatsakis (Apr 10 2019 at 14:48, on Zulip):
Week of What happens
May 20 release happens, we enable threads=1
May 27 testing period, week 1
June 3 testing period, week 2, assuming all goes well we enable threads=N
June 10 testing period, week 3
June 17 testing period, week 4, end of week is "d-day"
June 24 "decision day" -- either back out, or let it ride the trains
July 1 we cut the beta
Alex Crichton (Apr 10 2019 at 14:49, on Zulip):

I would say we could probably enable threads=1 on nightly in this cycle if we're confident, no?

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

ok, so that's different from what @Alex Crichton just said :)

Alex Crichton (Apr 10 2019 at 14:49, on Zulip):

(although maybe turn it back off just before the branch to beta)

Alex Crichton (Apr 10 2019 at 14:49, on Zulip):

(it is different from what I said)

nikomatsakis (Apr 10 2019 at 14:49, on Zulip):

ok, so that's different from what Alex Crichton just said :)

but mine has a prettier table

nikomatsakis (Apr 10 2019 at 14:49, on Zulip):

let me read what alex just wrote :)

nikomatsakis (Apr 10 2019 at 14:50, on Zulip):

ok, that is quite different from what alex said, yes

Alex Crichton (Apr 10 2019 at 14:50, on Zulip):

I'd basically propose "ASAP as we feel confident turn on threads=1 in nightly"

Alex Crichton (Apr 10 2019 at 14:50, on Zulip):

and delay threads=N in nightly to at most June 3 week

nikomatsakis (Apr 10 2019 at 14:50, on Zulip):

ok, that feels quite different from what we were discussing, but I'm open to it as well

nikomatsakis (Apr 10 2019 at 14:50, on Zulip):

do you mean that when we cut beta, it would have threads=1

Zoxc (Apr 10 2019 at 14:50, on Zulip):

I'd say we turn on thread=1 as soon as performance is good, if there's time left in the cycle

nikomatsakis (Apr 10 2019 at 14:51, on Zulip):

so I think that tying this to release cycles (Vs 2 week increments) is also good

Alex Crichton (Apr 10 2019 at 14:51, on Zulip):

that depends on if we have threads=1 at the beta cut, on performance numbers

nikomatsakis (Apr 10 2019 at 14:51, on Zulip):

it was what I initially wanted :) but I thought we wanted to move faster

Alex Crichton (Apr 10 2019 at 14:51, on Zulip):

if threads=1 is so bad we can't live with ourselves we could turn it back off just before beta

nikomatsakis (Apr 10 2019 at 14:51, on Zulip):

that depends on if we have threads=1 at the beta cut, on performance numbers

right, so, if all goes well, a "parallel capable, but not enabled" rustc would ship as beta

Alex Crichton (Apr 10 2019 at 14:51, on Zulip):

right and that I imagine will be contentious and we probably won't want to do

nikomatsakis (Apr 10 2019 at 14:51, on Zulip):

perhaps we should also allow people to turn parallel on with that beta?

nikomatsakis (Apr 10 2019 at 14:52, on Zulip):

i.e., it's "parallel opt-in"

Alex Crichton (Apr 10 2019 at 14:52, on Zulip):

hm that's not a terrible idea actually

nikomatsakis (Apr 10 2019 at 14:52, on Zulip):

I forget what we did with incremental in this regard

nikomatsakis (Apr 10 2019 at 14:52, on Zulip):

but I personally think it makes sense

Alex Crichton (Apr 10 2019 at 14:52, on Zulip):

incremental was somewhat different where not using it didn't have a perf impact

Alex Crichton (Apr 10 2019 at 14:52, on Zulip):

but w/ threads not using it can cause problems

nikomatsakis (Apr 10 2019 at 14:52, on Zulip):

well it causes a perf impact

nikomatsakis (Apr 10 2019 at 14:52, on Zulip):

but not (we believe) correctness problems

nikomatsakis (Apr 10 2019 at 14:53, on Zulip):

regardless the thing I don't remember is if we exposed incremental on an opt-in basis also on stable

mw (Apr 10 2019 at 14:53, on Zulip):

we just boiled the frog slowly with incremental :)

nikomatsakis (Apr 10 2019 at 14:53, on Zulip):

before we made it the default

nikomatsakis (Apr 10 2019 at 14:53, on Zulip):

anyway, I would personally favor that we enable parallel support but "opt-in" for 1 release cycle, and we ship it like that (presuming we haven't backed it out)

mw (Apr 10 2019 at 14:54, on Zulip):

we might have stabilized it in the compiler

nikomatsakis (Apr 10 2019 at 14:54, on Zulip):

it feels simpler

mw (Apr 10 2019 at 14:54, on Zulip):

but cargo would not default to it

nikomatsakis (Apr 10 2019 at 14:54, on Zulip):

I don't like the idea of us having to do some complex dance where beta turns it off and is not the code we've been testing etc

Alex Crichton (Apr 10 2019 at 14:54, on Zulip):

alright so this sounds like a plan? Shoot for threads=1 by the next release, then shoot for threads=N on the next release

Alex Crichton (Apr 10 2019 at 14:54, on Zulip):

May 23 == threads=1
July 4 == threads=N

mw (Apr 10 2019 at 14:55, on Zulip):

sgtm

nikomatsakis (Apr 10 2019 at 14:55, on Zulip):

I think as long as we are clear that we are moving towards "parallel by default" and that we have no major regressions, it's ok -- particularly if you can opt-in on stable, which would also help to eliminate regressions (unless there are bugs)

nikomatsakis (Apr 10 2019 at 14:55, on Zulip):

So I want to be clear on this point: are we allowing opt-in on stable ? (I think we should)

nikomatsakis (Apr 10 2019 at 14:55, on Zulip):

but it's advertised as being "experimental", hence it is not the default

mw (Apr 10 2019 at 14:56, on Zulip):

yes

Alex Crichton (Apr 10 2019 at 14:56, on Zulip):

agreed yes we should

Alex Crichton (Apr 10 2019 at 14:56, on Zulip):

so by May 23 we promote -Zthreads to something like -Cthreads

nikomatsakis (Apr 10 2019 at 14:56, on Zulip):

ok. So now the question of availability -- what exactly does it take to do this? It seems like it mostly require monitoring the internals thread and bugs filed

nikomatsakis (Apr 10 2019 at 14:56, on Zulip):

I wonder if we should involve the release team in this discussion

nikomatsakis (Apr 10 2019 at 14:56, on Zulip):

I kind of think yes :)

nikomatsakis (Apr 10 2019 at 14:56, on Zulip):

cc @simulacrum and @Pietro Albini

nikomatsakis (Apr 10 2019 at 14:57, on Zulip):

(times like these I wish everyone was on Zulip :stuck_out_tongue:)

nikomatsakis (Apr 10 2019 at 14:57, on Zulip):

so by May 23 we promote -Zthreads to something like -Cthreads

i was going to mention that -- we probably want to stabilize the option asap, but just have it be a no-op or something to start?

nikomatsakis (Apr 10 2019 at 14:58, on Zulip):

like, how specifically should "Opt-in" work? I imagine an environment variable is most convenient

mw (Apr 10 2019 at 14:58, on Zulip):

well, if we stabilize now, it would still only be available on nightly

mw (Apr 10 2019 at 14:58, on Zulip):

so that would be fine

nikomatsakis (Apr 10 2019 at 14:58, on Zulip):

yes

Alex Crichton (Apr 10 2019 at 14:58, on Zulip):

an env var that's ignored in non-parallel-capable compilers seems reasonable to me

mw (Apr 10 2019 at 14:59, on Zulip):

sounds good

nikomatsakis (Apr 10 2019 at 14:59, on Zulip):

I still use CARGO_INCREMENTAL=0 or whatever it is from time to time :)

mw (Apr 10 2019 at 14:59, on Zulip):

we have a tradition for using env vars like that

nikomatsakis (Apr 10 2019 at 14:59, on Zulip):

(mostly to sanity check if something is an incremental bug...it (almost) never is...)

nikomatsakis (Apr 10 2019 at 15:00, on Zulip):

do we therefore have to modify cargo to respect this variable?

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

nah I think it'd be RUSTC_THREADS=N

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

b/c cargo wouldn't do anything with it

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

unless we want cargo to pass -Cthreads=1 to rustc

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

via that env var

Zoxc (Apr 10 2019 at 15:00, on Zulip):

I think -j <threads> is a better option =P

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

(either way is fine by me)

mw (Apr 10 2019 at 15:00, on Zulip):

would cargo's job server just work?

nikomatsakis (Apr 10 2019 at 15:00, on Zulip):

that's basically what I was asking

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

-j won't work because you really do want parallel processes

nikomatsakis (Apr 10 2019 at 15:00, on Zulip):

I don't really have a strong opinion here on how it works but I think we should agree :)

Alex Crichton (Apr 10 2019 at 15:00, on Zulip):

but you don't want parallel rustc may

Alex Crichton (Apr 10 2019 at 15:01, on Zulip):

maybe*

nikomatsakis (Apr 10 2019 at 15:01, on Zulip):

does cargo always create a jobserver?

Alex Crichton (Apr 10 2019 at 15:01, on Zulip):

in the end it will all be -j but for now while we're testing they need to be separable

Alex Crichton (Apr 10 2019 at 15:01, on Zulip):

cargo does always create a jobserver, but it's not suitable for this I think

nikomatsakis (Apr 10 2019 at 15:01, on Zulip):

what do you mean?

Alex Crichton (Apr 10 2019 at 15:01, on Zulip):

-j and the jobserver govern processes as well as the threads of rustc

Zoxc (Apr 10 2019 at 15:01, on Zulip):

Why won't -j work? And we'll always use cargo's jobserver

nikomatsakis (Apr 10 2019 at 15:01, on Zulip):

reason I am asking: when rustc is compiling in parallel, we probably want a jobserver active, right? but I guess it must be active anyway because LLVM is parallel by default?

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

if you hit a parallel bug you want to turn off parallel rustc but not parallal cargo

nikomatsakis (Apr 10 2019 at 15:02, on Zulip):

yes, sorry, I"m asking a different question

nikomatsakis (Apr 10 2019 at 15:02, on Zulip):

I agree they should be different knobs

nikomatsakis (Apr 10 2019 at 15:02, on Zulip):

I'm mostly checking that if you TURN ON parallel rustc, you will get jobserver integration

Zoxc (Apr 10 2019 at 15:02, on Zulip):

cargo rustc -- -j1 will turn it off

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

@nikomatsakis yes turning on parallel rustc will always use a jobserver

nikomatsakis (Apr 10 2019 at 15:02, on Zulip):

also, RUSTC_THREADS=1 looks like use one thread, but we probably want a binary "on or off" flag, right?

nikomatsakis (Apr 10 2019 at 15:02, on Zulip):

in that case, maybe RUSTC_THREADED=1 ?

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

sgtm

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

that's a better idea yeah

mw (Apr 10 2019 at 15:03, on Zulip):

yes, one thread still means parallel LLVM

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

RUSTC_PARALLEL=1?

nikomatsakis (Apr 10 2019 at 15:03, on Zulip):

better

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

eh we can gloss over that

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

the fact that RUSTC_PARALLEL=0 still runs llvm in parallel

nikomatsakis (Apr 10 2019 at 15:03, on Zulip):

yeah I mean it's a nit pick :) but let's run with RUSTC_PARALLEL=1 to start

nikomatsakis (Apr 10 2019 at 15:03, on Zulip):

oh I see, yeah, whatever

nikomatsakis (Apr 10 2019 at 15:04, on Zulip):

we'll probably delete this option eventually anyway

Zoxc (Apr 10 2019 at 15:04, on Zulip):

Probably want to specify the threads. 8 threads is faster than me than 16 on 8 cores. Might not be true on Intel =P

nikomatsakis (Apr 10 2019 at 15:04, on Zulip):

Hmm, I don't think most people will want that. Maybe we want a way to specify the threads

nikomatsakis (Apr 10 2019 at 15:04, on Zulip):

ACtually

nikomatsakis (Apr 10 2019 at 15:04, on Zulip):

this would be a great point to ask people to give feedback on

nikomatsakis (Apr 10 2019 at 15:04, on Zulip):

maybe the value can be a percentage

Alex Crichton (Apr 10 2019 at 15:04, on Zulip):

I think -Z is fine for that for now? If necessary we can stabilize -j or -Cthreads in rustc itself

nikomatsakis (Apr 10 2019 at 15:05, on Zulip):

e.g., RUSTC_PARALLEL=1 means "Use 100% of cores" :)

nikomatsakis (Apr 10 2019 at 15:05, on Zulip):

RUSTC_PARALLEL=0.5 means "use 50% of cores"

Alex Crichton (Apr 10 2019 at 15:05, on Zulip):

nah I like the idea of 0/1 on/off

nikomatsakis (Apr 10 2019 at 15:05, on Zulip):

etc

nikomatsakis (Apr 10 2019 at 15:05, on Zulip):

nah I like the idea of 0/1 on/off

so, long term

Alex Crichton (Apr 10 2019 at 15:05, on Zulip):

because we want some heuristic in rustc eventually

nikomatsakis (Apr 10 2019 at 15:05, on Zulip):

people are not going to specify the number of threads

Alex Crichton (Apr 10 2019 at 15:05, on Zulip):

which just does everything automatically

nikomatsakis (Apr 10 2019 at 15:05, on Zulip):

but it might be helpful for us to have data on

Alex Crichton (Apr 10 2019 at 15:05, on Zulip):

true

nikomatsakis (Apr 10 2019 at 15:06, on Zulip):

i.e., if it's consistently true that 0.5 works best...

nikomatsakis (Apr 10 2019 at 15:06, on Zulip):

that's a simple heuristc :)

nikomatsakis (Apr 10 2019 at 15:06, on Zulip):

this seems like something people can help us with, if we are asking for feedback

Alex Crichton (Apr 10 2019 at 15:06, on Zulip):

ok seems reasonable

Alex Crichton (Apr 10 2019 at 15:06, on Zulip):

we parse RUSTC_PARALLEL as a float and multiply it by num_cpus::get

nikomatsakis (Apr 10 2019 at 15:06, on Zulip):

and take max(RUSTC_PARALLEL * NUM_CPUS, 1)

mw (Apr 10 2019 at 15:06, on Zulip):

haha, so weird

mw (Apr 10 2019 at 15:06, on Zulip):

I like it

Zoxc (Apr 10 2019 at 15:07, on Zulip):

That sounds horrible =P

nikomatsakis (Apr 10 2019 at 15:07, on Zulip):

since I guess you don't want to compile with 0 threads :P

nikomatsakis (Apr 10 2019 at 15:07, on Zulip):

I don't really care exactly what we use, but I think we shouldn't require people to know how many cores they have :)

Alex Crichton (Apr 10 2019 at 15:07, on Zulip):

sorry I don't know how to thumbs up a thing but I would if I could

nikomatsakis (Apr 10 2019 at 15:07, on Zulip):

haha

Zoxc (Apr 10 2019 at 15:07, on Zulip):

And I don't like RUSTC_PARALLEL as a stable option

nikomatsakis (Apr 10 2019 at 15:08, on Zulip):

I didn't imagine it as "stable" in the sense of supported long term, but maybe that's problematic

mw (Apr 10 2019 at 15:08, on Zulip):

I don't think RUSTC_PARALLEL would be around forever, right?

nikomatsakis (Apr 10 2019 at 15:08, on Zulip):

the nice thing about env vars is we can just ignore them

mw (Apr 10 2019 at 15:09, on Zulip):

what would you propose, @Zoxc ?

Zoxc (Apr 10 2019 at 15:10, on Zulip):

Just use -j <threads>, which is pretty standard.

mw (Apr 10 2019 at 15:10, on Zulip):

and then use RUSTFLAGS/cargo rustc?

Zoxc (Apr 10 2019 at 15:10, on Zulip):

Yeah. People opting in will likely know how many cores they have

mw (Apr 10 2019 at 15:11, on Zulip):

sounds also reasonable to me

mw (Apr 10 2019 at 15:11, on Zulip):

although it might be confusing regarding parallel LLVM

Alex Crichton (Apr 10 2019 at 15:12, on Zulip):

I don't think this is appropriate for testing though, maybe long term it's fine to have just this

nikomatsakis (Apr 10 2019 at 15:12, on Zulip):

I don't really care that much :) I don't know that people will know how many cores they have

nikomatsakis (Apr 10 2019 at 15:12, on Zulip):

I don't know how many cores I have, for example :)

Alex Crichton (Apr 10 2019 at 15:12, on Zulip):

but this does not have an easy "just turn it on and let me test" switch

Alex Crichton (Apr 10 2019 at 15:12, on Zulip):

we need to collect data on what we'll eventually turn on, which isn't where everyone will be choosing how many cores to give us

nikomatsakis (Apr 10 2019 at 15:12, on Zulip):

my main goal was that we should be able to tell people

nikomatsakis (Apr 10 2019 at 15:12, on Zulip):

"run these two commands and report to us the numbers"

Alex Crichton (Apr 10 2019 at 15:12, on Zulip):

furthermore RUSTFLAGS isn't actually a great proxy for this due to its cross-compilation behavior

Alex Crichton (Apr 10 2019 at 15:12, on Zulip):

where it's not passed to the host compilations (like build scripts and procedural macros) if you cross compile

nikomatsakis (Apr 10 2019 at 15:12, on Zulip):

"run these two commands and report to us the numbers"

and the fewer variations these require, the better

Alex Crichton (Apr 10 2019 at 15:12, on Zulip):

right

Alex Crichton (Apr 10 2019 at 15:13, on Zulip):

we should have "do this and report numbers" and then if they're willing "do this and tweak this parameter and report numbers"

Alex Crichton (Apr 10 2019 at 15:13, on Zulip):

the first, simple, thing should be what we will have the defaults as later (aka num_cpus::get)

mw (Apr 10 2019 at 15:13, on Zulip):

ok, I think I like the RUSTC_PARALLEL=factor solution best

mw (Apr 10 2019 at 15:14, on Zulip):

not as a stable option, but for testing the reasons seem convincing

Alex Crichton (Apr 10 2019 at 15:14, on Zulip):

I'm fine removing the factor wonkiness

Alex Crichton (Apr 10 2019 at 15:14, on Zulip):

and we could just add -j instead

nikomatsakis (Apr 10 2019 at 15:14, on Zulip):

(in the end, I don't care that much, but I think if we have people specify the number of cores, and we want real data, we should ask people to look things up, and there's also some confusion around e.g. hyperthreads etc)

mw (Apr 10 2019 at 15:17, on Zulip):

maybe we could make rustc print some information about the processor used

mw (Apr 10 2019 at 15:17, on Zulip):

making it easier for people to give us data?

mw (Apr 10 2019 at 15:18, on Zulip):

might cause unwanted commandline spam though

nikomatsakis (Apr 10 2019 at 15:18, on Zulip):

anyway this is a somewhat minor point

nikomatsakis (Apr 10 2019 at 15:19, on Zulip):

at least we can discuss it separately for sure

nikomatsakis (Apr 10 2019 at 15:19, on Zulip):

I don't have a strongly held opinion here, but I do think people should be able to turn off the "new" parallelism while keeping the old

Alex Crichton (Apr 10 2019 at 15:19, on Zulip):

so it sounds like for the time being add RUSTC_PARALLEL=0/1 and then add -j as well to rustc?

Alex Crichton (Apr 10 2019 at 15:20, on Zulip):

where -j defaults to some good heuristic we develop and RUSTC_PARALLEL=0 disables all parallelism we're testing here

Alex Crichton (Apr 10 2019 at 15:20, on Zulip):

and everything is always governed by cargo's jobserver

mw (Apr 10 2019 at 15:20, on Zulip):

sounds a bit hard to explain

nikomatsakis (Apr 10 2019 at 15:21, on Zulip):

it does sound strictly worse :)

nikomatsakis (Apr 10 2019 at 15:21, on Zulip):

let's leave this unsettled for a second and back up

nikomatsakis (Apr 10 2019 at 15:22, on Zulip):

I just want to sketch out overall plan and make sure I understand it:

nikomatsakis (Apr 10 2019 at 15:23, on Zulip):
Release Behavior
1.36 Supports parallel on an opt-in basis, controlled by RUSTC_PARALLEL=1, some way to specify number of cores
1.37 Supports parallel on an opt-out basis, controlled by RUSTC_PARALLEL=0, some way to specify number of cores
1.38 Supports parallel by default, no opt-out other than -j1?
nikomatsakis (Apr 10 2019 at 15:23, on Zulip):

I'm not sure about this last point

nikomatsakis (Apr 10 2019 at 15:24, on Zulip):

but I imagine that long-term we want the question of e.g. LLVM vs other parallelism to just kind of go away

Zoxc (Apr 10 2019 at 15:25, on Zulip):

*-j1

Alex Crichton (Apr 10 2019 at 15:25, on Zulip):

well so there's one thing missing from that sketch, which is for the 1.36 release we should probably have a way for data collection where users specify the number of cores

Alex Crichton (Apr 10 2019 at 15:25, on Zulip):

(if we primarily want that release to be a data collection one)

nikomatsakis (Apr 10 2019 at 15:25, on Zulip):

Right, that's the sort of undecided bit I guess

Alex Crichton (Apr 10 2019 at 15:25, on Zulip):

ok, that's also fine by me :)

nikomatsakis (Apr 10 2019 at 15:27, on Zulip):

So what are the concrete steps we need?

mw (Apr 10 2019 at 15:27, on Zulip):

criteria for when we make parallel=1 the default

nikomatsakis (Apr 10 2019 at 15:27, on Zulip):
mw (Apr 10 2019 at 15:28, on Zulip):

sounds good

mw (Apr 10 2019 at 15:30, on Zulip):

so what were the criteria again, did we settle on them?

Alex Crichton (Apr 10 2019 at 15:30, on Zulip):

I would say "<5% or <5s compile time regression" for making -j1 the default

Alex Crichton (Apr 10 2019 at 15:31, on Zulip):

(on perf.r-l.o benchmarks)

nikomatsakis (Apr 10 2019 at 15:31, on Zulip):

5s is..probably fine, maybe a bit higher

mw (Apr 10 2019 at 15:31, on Zulip):

5s seems a bit much for small crates

nikomatsakis (Apr 10 2019 at 15:31, on Zulip):

sorry, I meant, maybe a bit higher than I would like

Alex Crichton (Apr 10 2019 at 15:31, on Zulip):

heh we're the ones both making the rules and following them so we can of course tweak :)

Alex Crichton (Apr 10 2019 at 15:32, on Zulip):

1s?

nikomatsakis (Apr 10 2019 at 15:32, on Zulip):

I was going to suggest 1s

nikomatsakis (Apr 10 2019 at 15:32, on Zulip):

I have no idea how that comports with the existing numbers :)

Alex Crichton (Apr 10 2019 at 15:32, on Zulip):

we can also play it by ear and tweak if that feels wrong

Alex Crichton (Apr 10 2019 at 15:32, on Zulip):

we'll know if it feels right nonetheless

nikomatsakis (Apr 10 2019 at 15:32, on Zulip):

In terms of the criteria for whether to "go forward" or "revert" during the experimental period, I'd be inclined to use the same thresholds, but for any known crate? Is that too strict?

nikomatsakis (Apr 10 2019 at 15:33, on Zulip):

we can also play it by ear and tweak if that feels wrong

yes, I think it's ok

mw (Apr 10 2019 at 15:33, on Zulip):

ok

Alex Crichton (Apr 10 2019 at 15:33, on Zulip):

I would be stricter to turn on parallel by default

mw (Apr 10 2019 at 15:33, on Zulip):

we can make various teams sign off on it once we have numbers

Alex Crichton (Apr 10 2019 at 15:33, on Zulip):

something like "at least 10% average improvement across known crates"

mw (Apr 10 2019 at 15:35, on Zulip):

do we have a list of PRs we want to land before checking for the first time?

Zoxc (Apr 10 2019 at 15:35, on Zulip):

5% might be a bit low. I'd rather have it on right now. Given the significant speedups to the slowest cases

mw (Apr 10 2019 at 15:38, on Zulip):

/me has to run soon

nikomatsakis (Apr 10 2019 at 15:39, on Zulip):

yeah, me too

nikomatsakis (Apr 10 2019 at 15:40, on Zulip):

5% might be a bit low. I'd rather have it on right now. Given the significant speedups to the slowest cases

yeah, this might be true. Let's say 5-10% and use our best judgement :)

nikomatsakis (Apr 10 2019 at 15:40, on Zulip):

something like "at least 10% average improvement across known crates"

this is a good idea to establish something here too

Zoxc (Apr 10 2019 at 15:43, on Zulip):

I'd rather just turn it on on nightly right now and let it ride to beta if we get the -Z thread=1 case <5%

Zoxc (Apr 10 2019 at 15:44, on Zulip):

It doesn't really matter if nightly is a bit slower for a bit

mw (Apr 10 2019 at 15:45, on Zulip):

Yes, I'd say we wait for the promising PRs to land, measure, and probably turn it on, unless something is really slow

Zoxc (Apr 10 2019 at 15:47, on Zulip):

Nothing is really slow right now though. We'd have to turn it on and ask people to find such cases

mw (Apr 10 2019 at 15:48, on Zulip):

Yes, I'd be fine with the current state. I just would want to make sure the changes in the meantime didn't regress anything

mw (Apr 10 2019 at 15:49, on Zulip):

OK, I have to go

mw (Apr 10 2019 at 15:49, on Zulip):

I think we made a lot of progress :)

mw (Apr 10 2019 at 15:49, on Zulip):

:wave:

nikomatsakis (Apr 10 2019 at 16:15, on Zulip):

here is my attempt to summarize the plan:

https://gist.github.com/nikomatsakis/4263d4f55ff290c7c46993035dbeb091

@Zoxc, @mw , @Alex Crichton can y'all give it a look?

Alex Crichton (Apr 10 2019 at 16:18, on Zulip):

@nikomatsakis that looks great!

Alex Crichton (Apr 10 2019 at 16:19, on Zulip):

Question: Do we also require an average improvement of some % to be reported? On which tests?

I would argue "no" in that we already have clear data that we're going to see some great improvements, so part of the testing period for parallel-on-by-default will be to ensure that we achieve this goal of "the average user reports improvement"

Pietro Albini (Apr 10 2019 at 16:20, on Zulip):

catched up with all the scrollback :D

Pietro Albini (Apr 10 2019 at 16:20, on Zulip):

I probably miss a thing, do you plan to experiment only on nightly or also stable?

Zoxc (Apr 10 2019 at 16:24, on Zulip):

@Pietro Albini Turn it on on nightly and let it ride to stable, unless problems appear

Pietro Albini (Apr 10 2019 at 16:24, on Zulip):

hmm, can we afford to do the whole experimentation on nightly?

Pietro Albini (Apr 10 2019 at 16:25, on Zulip):

not feeling too strong about this, but experimenting on stable just sounds wrong

Pietro Albini (Apr 10 2019 at 16:25, on Zulip):

even though if it rides the trains without any issue is probably fine

Zoxc (Apr 10 2019 at 16:26, on Zulip):

@nikomatsakis That should probably say 1:1 core to thread ratio instead of 50% of cores =P

nikomatsakis (Apr 10 2019 at 16:28, on Zulip):

not feeling too strong about this, but experimenting on stable just sounds wrong

it's not so much that we are experimenting on stable I don't thikn

Pietro Albini (Apr 10 2019 at 16:32, on Zulip):

hmm, yeah, I don't feel too strongly on this :)

nikomatsakis (Apr 10 2019 at 16:38, on Zulip):

it was mostly that we'd let it ride the trains -- but the "active experiment" is on nightly

nikomatsakis (Apr 10 2019 at 16:38, on Zulip):

in other words, if the "opt-out" variant is a success, then it rides the trains, but the active experiment is now the opt-in variant (which is on nightly)

nikomatsakis (Apr 10 2019 at 16:39, on Zulip):

(I also don't feel that strongly, I just wasn't crazy about having us change things just before beta branches if we don't have to)

simulacrum (Apr 10 2019 at 16:39, on Zulip):

I'm fine with this riding the trains -- we're basically not changing behavior beyond maybe speed; and presumably in some future we'd never make backwards-incompatible changes to these env variables or flags

simulacrum (Apr 10 2019 at 16:40, on Zulip):

(We could stop using them, but that's not a breaking change)

nikomatsakis (Apr 10 2019 at 16:40, on Zulip):

Right. One nice thing about it riding the trains is

nikomatsakis (Apr 10 2019 at 16:40, on Zulip):

if it's working well for you

nikomatsakis (Apr 10 2019 at 16:40, on Zulip):

you can start using it sooner :)

mw (Apr 17 2019 at 15:08, on Zulip):

that plan looks good, @nikomatsakis

mw (Apr 17 2019 at 15:09, on Zulip):

I think we'll want people to report what kind of CPU they have

mw (Apr 17 2019 at 15:09, on Zulip):

i.e. core count, hyperthreading, maybe model

mw (Apr 17 2019 at 15:10, on Zulip):

it makes a difference if I'm using all cores on a 8/16 core machine vs a 2/4 core machine

simulacrum (Apr 17 2019 at 15:42, on Zulip):

@mw I think if we want that it would be good to figure out how to get it out programmatically and give them a script (ideally like bash, perhaps) to run

simulacrum (Apr 17 2019 at 15:43, on Zulip):

that way we get fairly uniform stats

mw (Apr 18 2019 at 09:37, on Zulip):

@simulacrum yes that would be perfect

Last update: Nov 17 2019 at 06:55UTC