# Plan to test parallel rustc
**URL:** https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487
**Category:** announcements
**Created:** [December 16, 2019, 9:08pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487 "2019-12-16T21:08:56Z")
**Posts on this page:** 11
**Page:** 2
### Author:  [@kinnison](https://internals.rust-lang.org/u/kinnison)
#### Post date: [December 18, 2019, 5:00pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/21 "2019-12-18T17:00:07Z")
> [@josh](#):
>
> Ideally, I'd love to see a way for us to build "special" builds that rustup can install, that won't ever be installed with a simple `rustup update` or `rustup install nightly` , but will only get installed if specifically requested. Does that seem like something that would require an _excessive_ amount of work in rustup to enable?
From `rustup`'s perspective, we'd need to know what the channel name would be, and then we could add support for it. We're restricted to the three channels (stable, beta, nightly) currently, and we do some special handling for `nightly` so that'd need some decision-making (i.e. is this new channel more nightly or more beta?)
Otherwise probably not a huge amount of work, plus a release 😃
---
### Author:  [@josh](https://internals.rust-lang.org/u/josh)
#### Post date: [December 18, 2019, 5:04pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/22 "2019-12-18T17:04:20Z")
Would it be possible to have something a bit different than a channel, with no automatic `rustup update`, just custom builds that get installed by _name_ (or name and date)? Having to invent a channel name and issue a new rustup release is exactly what we'd want to avoid for each such experiment.
Would it be possible to have an "experiment" pseudo-channel, where there's no such thing as `rustup install experiment`, only `rustup install experiment-foo` or `rustup install experiment-foo-2019-12-18`?
---
### Author:  [@kinnison](https://internals.rust-lang.org/u/kinnison)
#### Post date: [December 18, 2019, 5:09pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/23 "2019-12-18T17:09:55Z")
Yes, in theory we could do that -- it'd essentially be a channel, just not one which rustup tries to update on demand. Regardless a new rustup release will be needed because currently the format of channel names is limited and rustup won't download something it doesn't think is a channel. I'm also considering a mode of `rustup toolchain install https://.....` which would allow arbitrary manifest URLs resulting in an installation. That'd allow people to try stuff from different buckets, or self-hosted channels in the future.
---
### Author:  [@josh](https://internals.rust-lang.org/u/josh)
#### Post date: [December 18, 2019, 6:08pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/24 "2019-12-18T18:08:36Z")
Any such installation should still require a signature; rustup should maintain a chain of trust. And given an official signature, it seems reasonable to expect the build to appear in an official location.
I'd be happy to work with you on a spec for rustup-installed experiments. This one could have been `experiment-parallel-2019-12-18`, for instance. How about `experiment-identifier` for any alphanumeric `identifier`, and optionally `experiment-identifier-date`, where `experiment-identifier` installs the latest `experiment-identifier-date`?
---
### Author:  [@kinnison](https://internals.rust-lang.org/u/kinnison)
#### Post date: [December 18, 2019, 9:24pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/25 "2019-12-18T21:24:15Z")
That sounds reasonable, and I agree that trust chains are critical. We can talk about that on Discord perhaps at some point when our timezones are compatible?
---
### Author:  [@pythoneer](https://internals.rust-lang.org/u/pythoneer)
#### Post date: [December 18, 2019, 10:22pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/26 "2019-12-18T22:22:25Z")
Don't know if this is better placed here or in the sister thread. But i am wondering if it would be helpful to assemble a script that would automatically install the needed compiler versions, has predefined crates to test against and invokes the different scenarios (full, incremental, check ...). Those predefined crates would be extendable with crates individual people care about. Idk how helpful it is to have different crates on different platforms/architectures. I think you would want to "pin" one set of variables (the predefined crates) and varying the cpu/os etc. but still have different crates people add to the list. I could run 3 or 4 crates "by hand" without loosing interest but i can run a script and let the machine run for an hour and do the laundry or washing dishes meanwhile while gathering a bigger dataset.
---
### Author:  [@Eh2406](https://internals.rust-lang.org/u/Eh2406)
#### Post date: [December 19, 2019, 3:09am UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/27 "2019-12-19T03:09:32Z")
BTW: Thanks to the working group for getting this far! It has taken a lot of work to get this all working, and I just wanted to thank you all.
---
### Author:  [@est31](https://internals.rust-lang.org/u/est31)
#### Post date: [December 19, 2019, 4:26pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/28 "2019-12-19T16:26:49Z")
This reminds me of the discussion to add a nightly-alt channel to rustup: [Add support for a nightly-alt toolchain · Issue #1099 · rust-lang/rustup · GitHub](https://github.com/rust-lang/rustup/issues/1099)
> [@Disabling LLVM assertions in Nightly builds?](https://internals.rust-lang.org/t/disabling-llvm-assertions-in-nightly-builds/5388):
>
> Building rustc (usually) involves building LLVM. One of LLVM’s compile-time configuration is whether to enable assertions. Currently, in rust-lang’s official builds, LLVM assertions are enabled in the Nightly channel, and disabled on Beta and Stable. I imagine that these assertions help catch some rustc bugs, but they also have a compiler performance cost. In [one particular benchmark](https://github.com/servo/servo/pull/15559#issuecomment-280003926), they added 16% to Servo’s compilation time in debug mode and 53% in release mode. “Rust should have a pleasant…
The proposal didn't materialize as the LLVM assertions were disabled unconditionally.
---
### Author:  [@Ixrec](https://internals.rust-lang.org/u/Ixrec)
#### Post date: [December 19, 2019, 8:12pm UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/29 "2019-12-19T20:12:07Z")
AFAIK, a huge part of the point of asking the public to test this is so that they can test it on _their_ code, including private codebases not published to [crates.io](http://crates.io), so asking everyone to use the same crates would not even be testing what we want to test anymore (especially since it's still limited to 4 threads by default, so a lot of hardware variation won't kick in yet).
> [@pythoneer](#):
>
> a script that would automatically install the needed compiler versions, ... and invokes the different scenarios
The first post of the sister thread basically is that already; it lists 10 shell commands that do all of these steps: [Help test parallel rustc!](https://internals.rust-lang.org/t/help-test-parallel-rustc/11503)
---
### Author:  [@pythoneer](https://internals.rust-lang.org/u/pythoneer)
#### Post date: [December 20, 2019, 8:31am UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/30 "2019-12-20T08:31:10Z")
> [@Ixrec](#):
>
> AFAIK, a huge part of the point of asking the public to test this is so that they can test it on _their_ code, including private codebases not published to [crates.io](http://crates.io), so asking everyone to use the same crates would not even be testing what we want to test anymore
I think you missed the Point of my post. I explicitly mentioned that it is possible to add crates you care about twice
> [@pythoneer](#):
>
> Those predefined crates would be extendable with crates individual people care about
> [@pythoneer](#):
>
> but still have different crates people add to the list
The "value" of "pinning" a certain set of crates that everybody runs is to eliminate a variable if values look out of place. What if i run my crate and the results are off? If we have results for "common" crates that looks good by everybody else expect on my machine we can narrow the problem down because it is likely that the problem is not within the specialty of my crate but with my platform that is causing the problem. Like on Notebooks, when the thread/core utilization rises it increases the temperature and may lead to throttling which would be visible in the compilation of the "common" crates as well. And it would still be useful because if i care about 10 crates it would still be helpful and the easier it is to gather more data the better. Running different crates on different platforms without a "baseline" to compare against makes it harder to investigate a problem when it emerges. People already reporting slowdowns – what is the cause, the platform or the specific crate? Everybody running a baseline set of crates AND their individual ones – by just adding them to a list the script is reading in – is an advantage from my perspective.
> [@Ixrec](#):
>
> The first post of the sister thread basically is that already; it lists 10 shell commands that do all of these steps
I see it still as very time consuming for doing this with 10 - 20 crates. I could easily let a machine do all the work while watching a movie – i don't think i would sit an hour in front of my PC watching it compile and repeatedly enter the same commands.
---
### Author:  [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)
#### Post date: [March 19, 2020, 8:31am UTC](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487/31 "2020-03-19T08:31:14Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
[Previous page](https://internals.rust-lang.org/t/plan-to-test-parallel-rustc/11487.md?page=1)