This benchmark takes 31% of our CI time, despite considerable time spent trying to optimize it. However, we have not found that it is particularly notable when compared to our other large crate benchmarks.

script-servo has also historically shown some amount of non-determinism in the CGU partioning which also makes it an annoying benchmark.

Most people profiling locally just disable it because of how long it takes.

r? @nnethercote

This benchmark takes 31% of our CI time, despite considerable time spent trying to optimize it. However, we have not found that it is particularly notable when compared to our other large crate benchmarks.

script-servo has also historically shown some amount of non-determinism in the CGU partioning which also makes it an annoying benchmark.

Most people profiling locally just disable it because of how long it takes.

r? @nnethercote

bors died so the build didn't get queued -- @lcnr, do you want to re-run try or we can invoke build on 9c509a323b82b57aae17bc2a2060471600a0307f?

From a "speed" perspective, do we have an idea of which is faster? I suspect the 1MB of output is faster personally, but maybe I'm wrong? We could also consider locking stdout in the loop instead of re-locking it on every iteration...

I don't think we can viably disable TCO. Plus, release + debuginfo is a common configuration, and we'd not want to hurt performance there.

I wouldn't mind a black_box where you suggest, but I suspect it won't help matters.

I'm fine with using bors to get the appropriate test outputs (we can just run it through as needed).

Let's add a new subdirectory and test files with // only-linux, // only-macos, // only-windows -- that way we can be sure this at least works on Tier 1 platforms. Ideally we'd have the same output across platforms but I'm not too worried if it's just the closure vanishing for whatever reason (which might even just be different unwinding implementation).

Reverts rust-lang/rustc-perf#738

It appears to be a performance regression (up 5 minutes on the collector).

4014.562306732s w/o shared cache 4160.392478718s w/ shared cache

Reverting.

@bors retry

I'm going to hold off on merging this until I finish a local collection with this on -- without, I see a full build taking 4014 seconds. If this is faster locally then I'll see if we can't reproduce that on the collector somehow before landing this.

Reverts rust-lang/rustc-perf#738

It appears to be a performance regression (up 5 minutes on the collector).

@bors r+ rollup=iffy -- not sure if the added test will have the exact same output on other platforms

Okay this does indeed seem to be a regression:

• 01:47:05 before this landed
• 01:51:52 after this landed

Nothing obviously slower landed in rustc in that time either. I am unsure yet if there's some room for wins here or if we should just revert.

This looks great. Could you squash the commits into just the one to clean up git history a bit?

I suspect that this PR might cause problems if there's cases or platforms where our mini-functions get elided regardless of the black box, but we can iron out the kinks in nightly -- I don't think we'll find them by just looking in this PR, and it's small enough that I am comfortable just landing it.

r=me with commits squashed

You likely need to edit the 32-bit tests (which are not run on 64-bit machines) -- I would personally just do so manually. I wish we had a better way to support developers in doing this.

I personally suspect that no matter what we do, adding this basically stabilizes that there's only two panic strategies -- there is all but guaranteed to be downstream breakage in the wild no matter how we go about stabilizing.

This also increases the chances of crates saying "I only work with panic = abort" or so, whereas today the lack of this cfg means that it is pretty hard to make that call as a crate author (unless in some very specialized domain, where unwinding is never permitted, but those seem like major exceptions).

Looking at the use cases given so far (though I recall @joshtriplett mentioning others, maybe you can elaborate?):

https://github.com/rust-lang/rust/issues/74301 notes should_panic tests behaving poorly in -Cpanic=abort mode. This is "expected" -- and also seems solvable without this feature. The compiler can annotate such tests specially in -Cpanic=abort mode and libtest can use the already existing process-per-test mode for them. Perhaps there's room for a #[in_a_process] flag as well that users can opt-in to.

https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 discusses a limitation of our compiletest infrastructure, rather than a language limitation. It does seem true that some tests / programs require panic=abort to be sound (or panic=unwind to work), but this cfg seems like the wrong way to go about that. Like mentioned around the oneof RFC, maybe it merits a dedicated compile_error_if!(panic = abort, "....") but not general cfg support.

I would not be opposed to automating this, but I personally think that it really does need a personal (human) touch with the current setup at least. Usually toolstate breakage is fixed out-of-tree -- sometimes spanning 4+ repositories -- and that progress is incredibly hard for a bot to find and track. While we could ask that folks update the main issue, ultimately, the assessment that needs to be made each time is:

• Is this issue at risk of stagnating? (e.g., rustfmt devs are stuck on how to upgrade)
• Are we close enough to a release (less than a week) that we should ping compiler team to coordinate fixing, bypassing tool devs?

I don't think automation can make either call today.

Previously, each benchmark would rebuild dependencies from scratch, which was somewhat inefficient: many dependencies in Rust are shared amongst crates (e.g., syn, serde). This shares them across all benchmarks.

The next step would be to go further, and share between build kinds (e.g., build scripts only need to be built once). But we don't actually have a good way of just building build scripts, so that's left out of scope for now. It is also unclear how big a win this would be.

I am struggling to gather local numbers (still getting environment setup on a new computer), but I suspect that regardless the discrepancy in available parallelism and such may mean that I wouldn't really reflect what happens in prod anyway. I'm going to merge this. It is passing CI, and it should not affect the final crate's builds. In the worst case we can revert and delete generated artifacts if something does go wrong unexpectedly.

rustc always uses threads for LLVM, at least, so it probably makes sense to just always include a thread ID.

I think I would personally prefer that we not try to introduce locks or anything into rustc itself but rather have a separate tool that parses and re-shuffles logger output -- is that feasible? Too hard?

Thanks! Is that something we could plausibly "fix", or does that seem too hard? I guess we're already encoding them as bitsets. Maybe we can skip recording all-zero bitsets and decode them appropriately as well? It may also be worth switching to a lower minimum bound -- u64 implies 64 generics which I expect is way above the normal amount for most functions?

I prefer to provide them on-demand as the exact setup can change over time, but just give me a ping whenever you need it!

Proposal

Summary and problem statement

We do not currently require users to specify which ABI an extern corresponds to, in any context. This can be confusing (e.g., see https://github.com/rust-lang/rust/pull/75030), and seems like an obvious case to fix. Requiring users to specify the ABI forces them to think through which ABI they want.

Motivation, use-cases, and solution sketches

The primary motivation is to ease reading code. Particularly with the introduction of "C-unwind" ABI, it seems increasingly true that knowing up front which ABI is associated with function pointers and function declarations is useful.

Prioritization

I think this best fits the targeted ergonomic wins -- similar to dyn, at least for me, seeing extern "C" is much clearer than just a bare extern. Though related to C Parity / embedded, it does not enable any new behavior that was absent previously.

Links and related work

C++ mandates only C and C++ ABIs, and requires an ABI to be specified on extern blocks, but not extern functions.

Initial people involved

No one beyond myself, at this point.

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Hm, no, that change just disabled the Azure try builder (we're on GHA now), but both ran the same docker container.

Maybe you're confusing the try builds for x86_64-gnu-llvm-8 which runs in PR CI? That does run tests.

Regardless, we can run tests in try or so if needed, happy to provide instructions on how to enable that today.

I am working on gathering local numbers for how much of a win this is -- it seems like it might actually be a loss (perhaps from increased copying) on CI...

That looks reasonable. I think the md5 hashing is presumably from encoding md5 hashes into debuginfo. Maybe we can consider some sort of partial hashing scheme -- many files are going to all be at some prefix, and we can pre-hash that prefix I guess?

Not sure how feasible such a cache would be though.

bors try has not run tests on linux (or any platform) by default for at least the last few months, and I think roughly a year or so now (maybe more). It only does a dist build. https://github.com/rust-lang-ci/rust/actions is your best bet for finding logs if they're not cross-linked from the PR the try build was invoked on for whatever reason.

I think we should try to add a UI test for this. My guess is we can do that with a run-fail test, like this one https://github.com/rust-lang/rust/blob/master/src/test/ui/test-panic-abort.rs

Previously, each benchmark would rebuild dependencies from scratch, which was somewhat inefficient: many dependencies in Rust are shared amongst crates (e.g., syn, serde). This shares them across all benchmarks.

The next step would be to go further, and share between build kinds (e.g., build scripts only need to be built once). But we don't actually have a good way of just building build scripts, so that's left out of scope for now. It is also unclear how big a win this would be.

@craterbot run name=beta-1.46-rustdoc-1 start=1.45.2 end=beta-2020-07-24 mode=rustdoc cap-lints=warn p=5

@craterbot run name=beta-1.46-1 start=1.45.2 end=beta-2020-07-24 mode=build-and-test cap-lints=warn p=10

Note: Please do not conduct triage on these runs with syncing with a release team member first. Thanks!

@craterbot retry

I don't think I've ever had a Rust project that was more than a week long and didn't always need release mode, but I agree that it probably varies quite a bit.

I think that this is probably still the right call, though.

One thing we could try is splitting the build dependencies of proc macros and build scripts apart - the latter matter much less, and always run once. But proc macros used for in-workspace crates are essentially guaranteed to be run hundreds of times, so optimizing them to shave of a few milliseconds can be helpful.

I think from scratch builds will indeed always be faster for this, but we also don't have a great handle on whether that matters today (i.e., if you're on CI you probably only care about them, but locally you usually care about tiny incremental rebuilds).

@bors r+

Cc @anp

We probably just want to ban track caller on main (and maybe any lang item function?)

@bors try @rust-timer queue

This does indeed look better - I guess LLVM is probably probably propagates the cold attribute on the panicking and decides not to inline, though in this case that's not a good idea.

cachegrind diffs are usually noiseless for me, or nearly so.

My guess is that someone with pretty decent hardware, just to avoid it being really painful, would need to build rustc before/after this PR, i.e., on 9be8ffcb0206fc1558069a7b4766090df7877659 and ac48e62db85e6db4bbe026490381ab205f4a614d and run cachegrind on a rustc compilation of helloworld. The diff between those should give us a start of an idea for how to fix this.

I've added this to my todo list.

This was a slight performance regression, of up to 1%. Perhaps one of the BTree PRs are at fault? I recall there being some known regressions there.

This was a 1.1% regression for rustdoc on small crates. Probably different inlining decisions made by LLVM, or so? Does not affect rustc.

This really leads to simpler assembly with optimizations? That seems pretty unfortunate, given that this is essentially equivalent. Do you have diffs of before/after assembly?

This was a slight performance win, as expected. Huge thanks to @oli-obk and @hawkw for all the work put in here to get us an even faster logging framework. :tada:

This was a slight performance regression, as expected.

https://gist.github.com/Mark-Simulacrum/151b4948d6bd1ab86b5c1d9b36ba64de is the current output of perf list on the collector.

As expected, this was a performance regression of up to 20% on smaller crates, essentially entirely due to increased amount of metadata decoding. https://github.com/rust-lang/rust/pull/75008 may be the first step in eliminating these losses.

This was a slight performance regression on the ctfe stress test.

I suspect we're optimizing more poorly or something like that?

This was a performance regression, likely due to https://github.com/rust-lang/cargo/pull/8560.

Looking at the results, it seems the two crates affected, cargo and script-servo, had a roughly 0.5s and 0.8s bump in macro expansion.

This is presumably an expected (if somewhat unfortunate) consequence of the above PR -- it was all but guaranteed to be a regression on perf.rust-lang.org, as we only benchmark "final binary/library" compilation rather than the whole build. https://github.com/rust-lang/cargo/pull/8560 can only help full, post-cargo clean, builds.

This was a small perf improvement, as expected.

@bors r-

This seems to be a syntax errror (note - even PR CI didn't run).

The workflow is not valid. .github/workflows/ci.yml (Line: 578, Col: 7): Unexpected value 'fast-fail'

Successful merges:

• #74759 (add unsigned_abs to signed integers)
• #75056 (Lint path statements to suggest using drop when the type needs drop)
• #75058 (Clarify reuse of a BTreeMap insert support function and treats split support likewise)
• #75081 (Fix logging for rustdoc)
• #75083 (Do not trigger unused_braces for while let)
• #75095 (ci: disable fast-fail on auto-fallible)
• #75103 (Disable building rust-analyzer on riscv64)

Failed merges:

r? @ghost

@bors r-

The workflow is not valid. .github/workflows/ci.yml (Line: 578, Col: 7): Unexpected value 'fast-fail'

From https://github.com/rust-lang-ci/rust/actions/runs/193864895

Closing.

:+1: seems reasonable.

Perf triage:

This was a slight regression. This seems unexpected. Perhaps metadata sizes increased so we're reading more from disk? It would be good to investigate this further.

Perf triage:

This was a 2.5% regression on stress tests and a 1-2% loss on serde and futures (real world tests). This was expected.

@davidtwco, @wesleywiser -- could someone follow up on this being a performance-neutral PR? Thanks!

Hm -- I would expect that we could implement sorting almost as efficiently on two slices as one? We still have Index/IndexMut impls, so anything a sort would need to do seems like it should be essentially just as fast.

I don't think that's necessary. We do have #[unwind(aborts)] but using it throughout here is probably a bad idea - maybe not, not sure.

One question I have -- should we be documenting this as an extensible set, i.e., panic = "somethingelse" would perhaps eventually be added? I note that the tests here, for example, explicitly use not(panic = "abort") in a few places.

I can't think of other panic implementation strategies that would be reasonable for code to gate on, but I'm not very familiar with the possibilities here.

One option, if we're concerned about this, is to designate aborting as "special" (since it is the immediate termination option) and only add that (or just leave unwind unstable indefinitely).

Seems like a clear win. I don't think this is observable beyond the panic message being (much) better.

@bors r+

This shouldn't be made into a safety section (that only makes sense for unsafe functions). However, adding a bit of text saying something like "panicking here leads to UB (or aborts) elsewhere in this module" would be fine.

@bors r+

# Setting this will override the `use-lld` option for Rust code when targeting MSVC.