-
Notifications
You must be signed in to change notification settings - Fork 190
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
Add getrandom_uninit(dest: &mut [MaybeUninit<u8>]) -> ...
.
#291
Conversation
Overall, I like this approach better than the one in #279 I think that reducing the amount of @newpavlov what are you thoughts here? |
@josephlr |
I've resolved all the comments that have been addressed, so the open comments should be the only stuff that has to change for this PR:
Other than that, this looks reasonable to me, and I would be open to merging it. |
Are we OK with regressing the performance of the normal
I agree with this. As for the potential node.js performance regression, I believe the best right solution is to change the wasm-bindgen declaration of The other question I have about this PR, though, is whether it actually makes a significant difference: Under what realistic circumstances is |
More notes on the performance: See rust-lang/rust#90595 and other bugs about I think the common good use of
I think such tiny array sizes are typical of what a good use of |
I patched in the benchmarks discussed above in 4719b5f, and tested on latest nightly. For 16 / 32 / 256 bytes, there's an incredibly small difference (within the margin of error):
For page-sized benchmarks, there's a consistent (over multiple runs) ~1% improvement:
For our "large" benchmarks (2 MiB), the tests get much noisier, sometimes |
On such large sizes page faults may have significant influence on performance measurements, depending on number of benchmark runs. It could be worth to check results by using pre-faulted heap allocated buffers. |
Personally, I think it's fine. The custom backend could be fixed in the next breaking release, while for node.js we would have to wait for changes in the bindings. I wonder about whether passing uninitialized buffers to
As the measurements show, the difference is quite small. But I think it's still a good practice to provide an API which allows users to trim all unnecessary overheads. I don't think zero-initializing buffers is a bottleneck for IO operations in most cases, but still people done a fair bit of work on |
Here is what a call looks like to
The only difference between this assembly and the equivalent that calls If we were to reorder/execute the instructions leading up to the call optimally then we should expect to see pretty much zero performance impact of those 4 instructions as the moves to memory should happen in parallel with the prologue work in Nonetheless, I'll push an updated version of the PR. |
I updated the PR. @newpavlov wrote:
extern "C" fn __getrandom_custom(dest: *mut u8, len: usize) -> u32 {
let f: fn(&mut [u8]) -> Result<(), $crate::Error> = $path;
let slice = unsafe { ::core::slice::from_raw_parts_mut(dest, len) };
match f(slice) {
Ok(()) => 0,
Err(e) => e.code().get(),
}
} |
This is correct. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good! I especially like the benchmark macro, it makes things much clearer.
I think the only unresolved issue is exactly how to handle the tests, but I can make those changes.
@newpavlov I think all the style/implementation concerns have been addressed here. If you still really think having this functionality is a good idea (despite the almost imperceptible performance impact), I would be OK with merging it. I added some additional benchmarks (for an AES-128 key, and for entire pages), and I ran them on my system with:
to reduce variance and give the best performance. As before, there was no performance difference:
|
Add a public API for filling an `&mut [MaybeUninit<u8>]`. This will primarily serve as the building block for more typeful APIs for constructing random arrays. Increase the MSRV to 1.36, as `MaybeUninit` was added in that release. Fixes rust-random#226.
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@newpavlov @briansmith I think everything is resolved here. I've made a few minor changes (see commits) and rebased onto latest master.
Does this PR look good to you?
ab78c81
to
8bf7c8d
Compare
getrandom_uninit_slice(dest: &mut [MaybeUninit<u8>]) -> ...
.getrandom_uninit(dest: &mut [MaybeUninit<u8>]) -> ...
.
This reflects the changes in #291 Signed-off-by: Joe Richey <joerichey@google.com>
This reflects the changes in #291
Signed-off-by: Joe Richey <joerichey@google.com>
Add a public API for filling an
&mut [MaybeUninit<u8>]
. This will primarily serve as the building block for more typeful APIs for constructing random arrays.Fixes #226.