| test gen_bytes_chacha12 ... bench: 331,914 ns/iter (+/- 10,978) = 3085 MB/s | |
| test gen_bytes_chacha20 ... bench: 536,861 ns/iter (+/- 65,229) = 1907 MB/s | |
| test gen_bytes_chacha8 ... bench: 256,353 ns/iter (+/- 27,435) = 3994 MB/s | |
| test gen_bytes_hc128 ... bench: 470,638 ns/iter (+/- 58,468) = 2175 MB/s | |
| test gen_bytes_os ... bench: 4,553,959 ns/iter (+/- 358,889) = 224 MB/s | |
| test gen_bytes_pcg32 ... bench: 457,278 ns/iter (+/- 13,650) = 2239 MB/s | |
| test gen_bytes_pcg64 ... bench: 412,717 ns/iter (+/- 13,310) = 2481 MB/s | |
| test gen_bytes_pcg64mcg ... bench: 332,267 ns/iter (+/- 8,797) = 3081 MB/s | |
| test gen_bytes_std ... bench: 501,458 ns/iter (+/- 9,984) = 2042 MB/s | |
| test gen_bytes_step ... bench: 275,890 ns/iter (+/- 25,240) = 3711 MB/s |
| //! Generate a flat scene, nothing more. | |
| use terr::{heightmap::Heightmap, unbounded::Perlin}; | |
| use nalgebra::{Point3, Vector3}; | |
| use kiss3d::{window::Window, light::Light}; | |
| use rand::thread_rng; | |
| use rand_distr::{Distribution, UnitCircle, Exp1}; | |
| use ncollide3d::transformation::ToTriMesh; | |
| fn main() { |
| //! Question: how many zeros can PCG output? | |
| //! | |
| //! Output of 0 implies that xorshifted == 0. We can rewrite xorshifted: | |
| //! ((state >> 45) ^ (state >> 27)) as u32 == 0 | |
| //! As a bit slice: | |
| //! oldstate[45..64].extend(0) ^ oldstate[27..59] == 0 | |
| //! Thus: | |
| //! oldstate[45..64] ^ oldstate[27..46] == 0 | |
| //! and oldstate[46..59] == 0 | |
| //! |
| /// Read a `u32` from a byte sequence, in litte-endian order | |
| /// | |
| /// Consider usage with the `arrayref` crate. | |
| pub fn read_u32(bytes: &[u8; 4]) -> u32 { | |
| // TODO: check; also isn't the only code difference the read type? | |
| // TODO: but since this is unused we could just remove it! | |
| // On platforms where unaligned reads are safe, do a simple read | |
| #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] { | |
| unsafe{ *(bytes as *const [u8; 4] as *const u32) }.to_le() |
There are a couple of core questions to this proposal:
rand crate API at this point?For now, I'll assume that breakage is acceptable and try to look at multiple
| Questions and potential changes | |
| ============= | |
| Organisation and policies | |
| -------------- | |
| Should all RNGs be moved to a sub-module? E.g. `rng::isaac::IsaacRng` inside `rand` crate. | |
| ### RNG implementations |
| dhardy@localhost:~/other/pippin$ cargo clean | |
| dhardy@localhost:~/other/pippin$ cargo build | |
| Compiling num-traits v0.1.32 | |
| Compiling log v0.3.6 | |
| Compiling byteorder v0.5.1 | |
| Compiling regex-syntax v0.3.1 | |
| Compiling gcc v0.3.27 | |
| Compiling winapi-build v0.1.1 | |
| Compiling vec_map v0.6.0 | |
| Compiling hashindexed v0.1.0 |