summaryrefslogtreecommitdiff
path: root/crates/hashx/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* Allow clippy::collapsible_if to triggerGabriela Moldovan2026-02-161-0/+1
| | | | | | | | | `clippy::collapsible_if` started triggering after bumping the MSRV to 1.88. Since this triggers from a lot of places, and since there even are a couple of instances where we explicitly allow `clippy::collapsible_ifs`, I've opened #2342 for deciding what to do about it.
* maint/add_warning: Run script to add new warningGabriela Moldovan2026-01-271-0/+1
| | | | This adds the lint to all our crates.
* Fix name of clippy lint to unchecked_time_subtraction (2)Ian Jackson2025-11-061-1/+1
| | | | Run maint/add_warning
* Remove "doc_auto_cfg" incantation from all crates.Nick Mathewson2025-09-291-1/+1
| | | | This feature has been removed from nightly, in favor of doc_cfg.
* Temporarily suppress mismatched_lifetime_syntaxes.Gabriela Moldovan2025-07-071-0/+1
| | | | See #2060.
* clippy: deny `mod_module_files`Steven Engler2025-01-061-0/+1
| | | | | | Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
* add_warnings, *: Allow clippy::needless_lifetimesNick Mathewson2024-12-031-0/+1
| | | | | | | | In 1.83, this warning triggers on many of our crates. We're thinking of fixing them all, but for now, we're going to disable the warning. This is part of #1765.
* Re-run maint/add_warning.Nick Mathewson2024-05-061-2/+2
| | | | This commit is automatically generated.
* deny clippy::unchecked_duration_subtractiontrinity-1686a2024-02-291-0/+1
|
* Switch to FixedCapacityVec 0.1.0 from crates.ioIan Jackson2023-09-061-2/+0
|
* hashx: FixedCapacityVec: Move into its own moduleIan Jackson2023-08-241-0/+2
|
* hashx: New approach to avoid memcpy in ProgramMicah Elizabeth Scott2023-08-211-6/+5
| | | | | | | | | | | | | | | | | | | | | I was trying to eliminate all the places where we copied a Program (about 4100 bytes) except for the one final copy into a Box; but that approach was proving too annoying. Even returning a Program via Result will cause multiple unnecessary copies that don't optimize out. This patch switches approaches, and instead allocates a Vec<Instruction> presized to the correct capacity. This allocation is made as early as possible and retained for the lifetime of the program if necessary. This means we'll never avoid a heap allocation, but we can always avoid extra copies and we don't need a separate Box for interpreted programs. Performance effects are subtle. Overall wallclock time doesn't change much. Cachegrind shows some accesses moving up from RAM to L2 cache. Using GDB to probe memcpy sizes shows that large (>1024b) memcpy are now totally gone in the generate-interp test. Signed-off-by: Micah Elizabeth Scott <[email protected]>
* Run add_warnings on all files.Nick Mathewson2023-08-041-2/+2
|
* tor-hspow, equix, hashx: Comment tweaksMicah Elizabeth Scott2023-07-271-15/+15
| | | | | | Making a few comment tweaks suggested in review feedback. Signed-off-by: Micah Elizabeth Scott <[email protected]>
* hashx: Simplify hash_to_bytes, only support fixed output widthMicah Elizabeth Scott2023-07-271-4/+4
| | | | | | | | | | | | 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 <[email protected]>
* hashx: use RngCore for HashX's internal PRNGMicah Elizabeth Scott2023-07-271-10/+36
| | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* hashx: Implement Default for RuntimeOptionMicah Elizabeth Scott2023-07-271-11/+4
|
* Update equix, hashx, tor-hspow for new clippy defaultsMicah Elizabeth Scott2023-07-271-1/+1
| | | | Just running maint/add_warning after the rebase
* Reimplement HashX in RustMicah Elizabeth Scott2023-07-271-0/+212
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 <[email protected]>