Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arena: use specialization to avoid copying data #78569

Merged
merged 1 commit into from
Nov 21, 2020

Conversation

bugadani
Copy link
Contributor

@bugadani bugadani commented Oct 30, 2020

In several cases, a Vec or SmallVec is passed to Arena::alloc_from_iter directly. This PR makes sure those cases don't copy their data unnecessarily, by specializing the alloc_from_iter implementation.

@rust-highfive
Copy link
Collaborator

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 30, 2020
@bugadani
Copy link
Contributor Author

cc @est31

@varkor
Copy link
Member

varkor commented Nov 16, 2020

Apologies for taking so long; this slipped under my radar. I'm not familiar with this code, so I'm assigning to @Mark-Simulacrum based on git blame.

r? @Mark-Simulacrum

compiler/rustc_arena/src/lib.rs Outdated Show resolved Hide resolved
compiler/rustc_arena/src/lib.rs Outdated Show resolved Hide resolved
compiler/rustc_arena/src/lib.rs Outdated Show resolved Hide resolved
compiler/rustc_arena/src/lib.rs Outdated Show resolved Hide resolved
@bugadani bugadani force-pushed the arena-spec branch 4 times, most recently from 599683e to 43b83b3 Compare November 20, 2020 08:55
@bugadani
Copy link
Contributor Author

@Mark-Simulacrum I've done what I could. I've addressed your comments and reverted some changes based on those comments. For example, changes to write_from_iter are no longer part of this PR, as they aren't necessary any more.

@Mark-Simulacrum
Copy link
Member

@bors try @rust-timer queue

This should just be a win (or roughly neutral), but let's check. r=me otherwise.

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Nov 20, 2020

⌛ Trying commit 43b83b334130ef066d8518ca2a125779399ccd73 with merge aa21b48c4d75183274998a446bae14e98053637a...

@bors
Copy link
Contributor

bors commented Nov 20, 2020

☀️ Try build successful - checks-actions
Build commit: aa21b48c4d75183274998a446bae14e98053637a (aa21b48c4d75183274998a446bae14e98053637a)

@rust-timer
Copy link
Collaborator

Queued aa21b48c4d75183274998a446bae14e98053637a with parent c9c57fa, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (aa21b48c4d75183274998a446bae14e98053637a): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

@bugadani
Copy link
Contributor Author

Interesting. I wonder if I see the results correctly - an increase in instruction counts, but in the same time, looking at the detailed results, a decrease in times? For example, this report belongs to a 0.5% instruction count regression, but shows a -0.3% total time diff: https://perf.rust-lang.org/detailed-query.html?commit=aa21b48c4d75183274998a446bae14e98053637a&base_commit=c9c57fadc47c8ad986808fc0a47479f6d2043453&benchmark=match-stress-enum-check&run_name=incr-unchanged

Hmm.

@Mark-Simulacrum
Copy link
Member

I would say that this is perhaps a slight regression in instruction counts, but overall a win on cycles -- https://perf.rust-lang.org/compare.html?start=c9c57fadc47c8ad986808fc0a47479f6d2043453&end=aa21b48c4d75183274998a446bae14e98053637a&stat=cycles%3Au on non-incremental benchmarks. I am inclined to land it based on these performance results; it does not seem like an obvious win yet, but it does seem like something we should be doing to try and avoid potential problems for the cases optimized here.

@Mark-Simulacrum
Copy link
Member

Ok, r=me with commits squashed

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 20, 2020

📌 Commit e93a463 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 20, 2020
@est31
Copy link
Member

est31 commented Nov 20, 2020

Are the cycle numbers always this noisy? There is a 5% on incr-unchanged on the encoding-check benchmark. Apparently most of the slowdown comes from early_lint_checks being 50% slower. https://perf.rust-lang.org/detailed-query.html?commit=aa21b48c4d75183274998a446bae14e98053637a&base_commit=c9c57fadc47c8ad986808fc0a47479f6d2043453&benchmark=encoding-check&run_name=incr-unchanged

Should this worry us?

@Mark-Simulacrum
Copy link
Member

Note that the 50% there is a wall clock measurement of 6ms, which is almost certainly noise. Cycle measurements frequently have noise in the 5% range on clean benchmarks; for incremental unchanged benchmarks they can be even noisier since there's less overall cycles on those.

I am not particularly worried.

@est31
Copy link
Member

est31 commented Nov 20, 2020

@Mark-Simulacrum thanks for the info!

@bors
Copy link
Contributor

bors commented Nov 20, 2020

⌛ Testing commit e93a463 with merge 432d116...

@bors
Copy link
Contributor

bors commented Nov 21, 2020

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 432d116 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 21, 2020
@bors bors merged commit 432d116 into rust-lang:master Nov 21, 2020
@rustbot rustbot added this to the 1.50.0 milestone Nov 21, 2020
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #78569!

Tested on commit 432d116.
Direct link to PR: #78569

💔 rls on linux: test-pass → test-fail (cc @Xanewok).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Nov 21, 2020
Tested on commit rust-lang/rust@432d116.
Direct link to PR: <rust-lang/rust#78569>

💔 rls on linux: test-pass → test-fail (cc @Xanewok).
@bugadani bugadani deleted the arena-spec branch November 21, 2020 07:07
mem::forget(self);
slice::from_raw_parts_mut(start_ptr, len)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there are quite a bit of code duplication here, shouldn't it be refactored?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's not intentionally duplicated, but I couldn't find a way to make it significantly nicer. Unfortunately, we can't use alloc_from_slice because it requires the items to be Copy.

pickfire added a commit to pickfire/rust that referenced this pull request Dec 5, 2020
nnethercote added a commit to nnethercote/rust that referenced this pull request Oct 3, 2023
It was added in rust-lang#78569. It's complicated and doesn't actually help
performance.
nnethercote added a commit to nnethercote/rust that referenced this pull request Oct 3, 2023
It was added in rust-lang#78569. It's complicated and doesn't actually help
performance.

Also, add a comment explaining why the two `alloc_from_iter` functions
are so different.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 4, 2023
…llot

Remove the `TypedArena::alloc_from_iter` specialization.

It was added in rust-lang#78569. It's complicated and doesn't actually help
performance.

r? `@cjgillot`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants