Skip to content

Specialize slice::fill with Copy type and u8/i8/bool #81874

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

Merged
merged 2 commits into from
Feb 27, 2021

Conversation

tesuji
Copy link
Contributor

@tesuji tesuji commented Feb 8, 2021

I don't expect rustperf could measure any perf improvements with this changes
since slice::fill is newly added.

Godbolt link for this change: https://rust.godbolt.org/z/r3fzee.

r? @matthewjasper since this patch added new specialization.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 8, 2021
@rust-log-analyzer
Copy link
Collaborator

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
configure: rust.channel         := nightly
configure: rust.debug-assertions := True
configure: llvm.assertions      := True
configure: dist.missing-tools   := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: 
configure: run `python /checkout/x.py --help`
configure: 
---
Checking which error codes lack tests...
Found 436 error codes
Found 0 error codes with no tests
Done!
tidy error: /checkout/library/core/src/slice/specialize.rs:29: undocumented unsafe
tidy error: /checkout/library/core/src/slice/specialize.rs:39: undocumented unsafe
some tidy checks failed

command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "/checkout/obj/build"
expected success, got: exit code: 1

for item in self.iter_mut() {
*item = value;
}
}
Copy link
Member

@the8472 the8472 Feb 8, 2021

Choose a reason for hiding this comment

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

Instead of specializing separately on [u8] below you can do a if mem::size_of::<T>() == 1 here and call memset for any type that's 1 byte wide.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, that's another option. Will do that! Thanks.

Copy link
Contributor Author

@tesuji tesuji Feb 8, 2021

Choose a reason for hiding this comment

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

value now has 1-byte size. ptr::write_bytes only accepts u8 as second argument.
Should I transmute value to u8 ? Is it sound ?

Copy link
Contributor Author

@tesuji tesuji Feb 8, 2021

Choose a reason for hiding this comment

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

Even if I want to transmute, the compiler forbids me: https://rust.godbolt.org/z/a3bsYs

error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
  --> <source>:38:33
   |
38 |                 let value: u8 = std::mem::transmute(value);
   |                                 ^^^^^^^^^^^^^^^^^^^
   |
   = note: source type: `T` (this type does not have a fixed size)
   = note: target type: `u8` (8 bits)

Copy link
Member

Choose a reason for hiding this comment

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

transmute_copy should work

Copy link
Contributor Author

@tesuji tesuji Feb 9, 2021

Choose a reason for hiding this comment

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

Neat! That's really work! But I wonder if that those specific specialization for [u8] matters much with #81874 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

The advantage is that it doesn't rely on the optimizer, so it'll work in debug mode too or with less powerful backends.

With the size_of approach it only has to be implemented once instead of one specialization for each T.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't have strong opinion on this. I defer that to reviewer to decide.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @bjorn3. the8472 and I were discussing if other codegen backends could handle straight
for loop to copy item and make it to memcpy when item is 1-byte size.

Do you think cranelift could be benefited from this optimization ^^?

@tesuji tesuji changed the title Specialized slice::fill with Copy type and u8/i8 Specialized slice::fill with Copy type and u8/i8/bool Feb 8, 2021
}
}

impl SpecFill<u8> for [u8] {
Copy link
Contributor Author

@tesuji tesuji Feb 8, 2021

Choose a reason for hiding this comment

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

The only difference when not specialize for [u8] is that compiler emits a check whether the slice is empty
before the call to memcpy.
https://rust.godbolt.org/z/z9fbcT.

Maybe it is not worth to keep those specs for u8/i8/bool slice.

@tesuji tesuji changed the title Specialized slice::fill with Copy type and u8/i8/bool Specialize slice::fill with Copy type and u8/i8/bool Feb 9, 2021
@matthewjasper
Copy link
Contributor

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 14, 2021
@bors
Copy link
Collaborator

bors commented Feb 14, 2021

⌛ Trying commit 010e194 with merge 194efb9e2ffaa05d0d10f8cb6c97e5a83f763f5d...

@bors
Copy link
Collaborator

bors commented Feb 14, 2021

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

@rust-timer
Copy link
Collaborator

Queued 194efb9e2ffaa05d0d10f8cb6c97e5a83f763f5d with parent b86674e, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (194efb9e2ffaa05d0d10f8cb6c97e5a83f763f5d): 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 label: +S-waiting-on-review -S-waiting-on-perf

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 14, 2021
@m-ou-se
Copy link
Member

m-ou-se commented Feb 14, 2021

Note that slice::fill isn't used in the compiler, so a perf run doesn't really say anything here.

@tesuji
Copy link
Contributor Author

tesuji commented Feb 24, 2021

Friendly ping.

@matthewjasper
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Feb 27, 2021

📌 Commit 010e194 has been approved by matthewjasper

@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 Feb 27, 2021
@bors
Copy link
Collaborator

bors commented Feb 27, 2021

⌛ Testing commit 010e194 with merge ec7f8d9...

@bors
Copy link
Collaborator

bors commented Feb 27, 2021

☀️ Test successful - checks-actions
Approved by: matthewjasper
Pushing ec7f8d9 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 27, 2021
@bors bors merged commit ec7f8d9 into rust-lang:master Feb 27, 2021
@rustbot rustbot added this to the 1.52.0 milestone Feb 27, 2021
@tesuji tesuji deleted the spec_slice_fill branch February 28, 2021 01:28
@tesuji
Copy link
Contributor Author

tesuji commented Feb 28, 2021

Thanks for the merge. But quick note when things slipped is that some comments are not resolved.

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.

9 participants