In response to review feedback, explain that 'seed' here is more
for compatibility and convenience and not central to our goal of
fuzzing the program generator.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Fuzz testing for HashX. Uses a hook into the pseudorandom number
stream to test the program generator deeply on input that can
be mutated by the fuzzer. Confirms program generation by running
a small number of arbitrary test hashes, so we don't need to
understand the implementation-specific program format to test the
program generator.
We test four implementations in parallel this way, the compiled and
interpreted implementations included in both this crate and c-tor.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Propagates this setting from the outer Cargo.toml to the new
benchmark crates, since they no longer get the setting by
being included in the main workspace.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
It might be useful to keep these locked down for benchmark
reproducibility. Currently the hashx and equix crates are
fully separate.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This is a small batch of improvements for the equix and hashx
benchmarks. The headline feature is that we are now including
the C implementations (slightly modified from tevador's, hosted
as part of c-tor) and using them in apples-to-apples comparisons.
Minor features:
- Benchmarks moved to new nested crates, preventing their
dependencies from spilling into the main workspace build.
- Tests are now grouped
- We also test the performance of memory reuse where possible
- Code cleanup for per-runtime options
These benchmark builds will now automatically pull in the c-tor
git repo and build portions of it with a Rust wrapper. This uses
the 'cc' and 'bindgen' crates, so it requires a C compiler and
libclang on the host system.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This replaces the 'TODO' marker from earlier commits, using tevador's
copyright and license (LGPL 3.0 only) for the hashx and equix crates.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
I originally wrote this in an overcomplicated way, to avoid
frequent initialization of a RegisterWriter array. It turns out
that RegisterWriter can be fairly compact, so this extra level of
indirection isn't necessary or measurably helpful.
This still manages to avoid declaring RegisterWriter as Copy, by
using Default to initialize the array instead of an array constructor.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
In response to review feedback. The byte output is only needed
for unit tests right now, since Equi-X uses u64 output exclusively.
The optimization for shorter output widths can shave tiny amounts of
time off hash benchmarks, but in this case it's more helpful to avoid
introducing APIs that offer parameters with incomplete compile-time
range checking.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This refactors the random number generator used within HashX's program
generator so that it uses the rand::RngCore trait. The basic SipHash
powered u64 generator now implements RngCore, while a buffer layer
wraps this and provides u8 and u32 values as needed by the generator.
Some of this new RngCore layer is now exposed to the hashx crate's
public API. The intent is to allow external code to test, benchmark, or
fuzz the program generator by supplying its own random number stream.
Benchmarks show a small but confusing performance improvement
associated with this patch. About a 2% improvement in generation.
This could be due to the Rng changes. No change in compiled hash
execution performance. Even though this patch only touches program
generation, benchmarks show a 4% speedup in interpreted execution.
This seems most likely explained by instruction cache effects,
but I'm not sure.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
I was hoping most of the program generator would get inlined, so we can
resolve a lot of the edge cases at compile-time. This patch gets us
close to that, adding many inline attrs and rewriting RegisterSet with
explicit unrolling and storage types that are easier for the optimizer
to reason about.
From the disassembly of the program generator, it's now mostly one big
function with a jump table. From callgrind instruction profiles, there
are no longer obvious hotspots in register set scanning loops. It also
looks like we're often keeping per-register schedule information all
loaded into machine registers now.
Keeping the Rng entry points non-inlined for now seems to be slightly
better, by a percent or two.
There's some work left to do in compiled programs, and maybe room for
improvement in the Program representation too. That will be in a future
patch.
Benchmark shows about 20% improvement on my machine,
generate-interp time: [75.440 µs 75.551 µs 75.684 µs]
change: [-24.083% -23.775% -23.483%] (p = 0.00 < 0.05)
Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
5 (5.00%) high mild
6 (6.00%) high severe
generate-x86_64 time: [96.068 µs 96.273 µs 96.540 µs]
change: [-18.699% -18.381% -18.013%] (p = 0.00 < 0.05)
Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
4 (4.00%) high mild
6 (6.00%) high severe
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This is a new pure Rust implementation of the HashX algorithm
designed by tevador for Tor's onion service proof of work puzzle v1.
HashX is a lightweight family of randomly generated hash functions.
A seed, via blake2 and siphash, drives a program generation model
which randomly selects opcodes and registers while following some
constraints that avoid timing stalls or insufficient hash mixing.
The execution of these hash funcions can be done using a pure Rust
interpreter, or about 20x faster using a very simple just in time
compiler based on the dynasm assembler crate. This has been
implemented for x86_64 and aarch64.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Nick Mathewson
Micah Elizabeth Scott