This builds, links, and runs the tests on `x86_64-apple-ios` using
[`dinghy`](https://github.com/sonos/dinghy). It moves the targets
which only Build/Link to their own job.
Signed-off-by: Joe Richey <joerichey@google.com>
The current action we are using is unmantained:
https://github.com/actions-rs/toolchain/issues/216
This replacement is faster, smaller, and more cachable.
We can also completely remove the toolchain step when testing with
cross, as cross handles configuration of its own toolchain.
Signed-off-by: Joe Richey <joerichey@google.com>
We can build and link just fine, but we cannot actually run the tests as
`wasm-bindgen-test-runner` hasn't yet added support.
Signed-off-by: Joe Richey <joerichey@google.com>
* Cleanup wasm32-wasi target
This change ensures that we only compile our WASI implementation for
32-bit targets. The interaction between the WASI proposal and the
memory64 proposal is not yet clear, [wasmtime does not yet support](
https://github.com/bytecodealliance/wasmtime/issues/3594#issuecomment-992590383)
using WASI with memory64, and many of the interfaces use 32-bit values
for pointers.
This change also reduces the use of `unsafe` from the wasi
implementation. As noted in #253, changes to `Errno` mean that we can't
get the error message from the raw error code, but we can avoid using
unsafe when converting this code to a NonZeroU32. This handling also
makes WASI behave more like our other targets, which also manually check
that errno is non-zero.
Signed-off-by: Joe Richey <joerichey@google.com>
* Disable default features for WASI crate
Similar to this crate, the `wasi` crate just uses a `std` feature to
implement `std::error::Errno`, which we don't use.
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
This PR adds some tests which make sure calls to getrandom (for both small and large buffers) "look" random.
While we could certainly add more complicated randomness tests, these simple tests are:
- Very easy to understand
- Don't require any external crates
- Makes sure we aren't doing something obviously stupid like
- forgetting [these lines](https://github.com/rust-random/getrandom/blob/bd0654fe70980583e51573e755bafa3b2f8342d9/src/rdrand.rs#L91-L95)
- failing to initialize every other byte
- initializing some significant fraction of bytes with a constant
As this tests all buffer sizes from 1 to 64, it also fixes#290.
Tests: Use custom tests to verify operations on empty slices are no-ops.
Reworking of #299 to keep our custom tests in a single file (and keep things better organized in general).
Fixes#216
This also adds two minor CI improvements:
- Do a full link on `freebsd`
- Build, Link, but don't run on `illumos`
- Use the stable toolchain for our Tier 2 Build-only targets
- Build (via `build-std`) for Tier 3 targets: `openbsd`, `dragonfly`, `haiku`
Signed-off-by: Joe Richey <joerichey@google.com>
* Rename benches/mod.rs to benches/buffer.rs
This naming makes more sense, especially if we add more benchmark
files.
Signed-off-by: Joe Richey <joerichey@google.com>
* Rework benchmarks to make it easier to get assembly.
This change:
- Move the benchmarks from mod.rs to buffer.rs
- Move the inner loop we benchmark into an `#[inline(never)]` function
- Includes instructions for getting the ASM for a specific benchmark
This should hopefully reduce the variance of these benchmarks and make
it easier to figure out if we are emitting the assembly or IR we expect
for a particular implementation.
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
* Add `getrandom_uninit(dest: &mut [MaybeUninit<u8>]) -> ...`.
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#226.
* Revert testing changes
Signed-off-by: Joe Richey <joerichey@google.com>
* Allow rdrand tests to work with new implementation
Signed-off-by: Joe Richey <joerichey@google.com>
* Add Additional benchmarks and buffer size
Signed-off-by: Joe Richey <joerichey@google.com>
* Use pointer casts instead of transmute
Signed-off-by: Joe Richey <joerichey@google.com>
* Avoid initializing the buffer in `getrandom_uninit` benchmarks.
* Benchmarks: Consume the result in `black_box`.
Signed-off-by: Joe Richey <joerichey@google.com>
Co-authored-by: Joe Richey <joerichey@google.com>
This allows users to get an actionable error message about this
particular problem. We also add detection for this problem.
Signed-off-by: Joe Richey <joerichey@google.com>
* add description about Cargo js feature
* add note about different crate types
* clean up
* Fix wording/grammer
* Remove "Indirect Depenencies" section
* Note that libraries shouldn't add their own JS feature
Signed-off-by: Joe Richey <joerichey@google.com>
Co-authored-by: Mauri Mustonen <mauri.mustonen@hotmail.com>
Co-authored-by: Joe Richey <joerichey@google.com>
This PR adds more benchmarks so we can get and accurate idea about two
things:
- What is the cost of having to zero the buffer before calling
`getrandom`?
- What is the performance on aligned, 32-byte buffers?
- This is by far the most common use, as its used to seed
usersapce CSPRNGs.
I ran the benchmarks on my system:
- CPU: AMD Ryzen 7 5700G
- OS: Linux 5.15.52-1-lts
- Rust Version: 1.62.0-nightly (ea92b0838 2022-05-07)
I got the following results:
```
test bench_large ... bench: 3,759,323 ns/iter (+/- 177,100) = 557 MB/s
test bench_large_init ... bench: 3,821,229 ns/iter (+/- 39,132) = 548 MB/s
test bench_page ... bench: 7,281 ns/iter (+/- 59) = 562 MB/s
test bench_page_init ... bench: 7,290 ns/iter (+/- 69) = 561 MB/s
test bench_seed ... bench: 206 ns/iter (+/- 3) = 155 MB/s
test bench_seed_init ... bench: 206 ns/iter (+/- 1) = 155 MB/s
```
These results were very consistent across multiple runs, and roughtly
behave as we would expect:
- The thoughput is highest with a buffer large enough to amoritize the
syscall overhead, but small enough to stay in the L1D cache.
- There is a _very_ small cost to zeroing the buffer beforehand.
- This cost is imperceptible in the common 32-byte usecase, where the
syscall overhead dominates.
- The cost is slightly higher (1%) with multi-megabyte buffers as the
data gets evicted from the L1 cache between the `memset` and the
call to `getrandom`.
I would love to see results for other platforms. Could we get someone to
run this on an M1 Mac?
Signed-off-by: Joe Richey <joerichey@google.com>
Joseph Richey
Thom Chiovoloni
Brian Smith
Mauri Mustonen
Artyom Pavlov
Autumn
Leonardo Yvens