| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This patch tries to make some of the expressions around NUM_INSTRUCTIONS
more convenient. We can import it directly where it's needed, but most
uses are replaced by new type aliases for InstructionArray and
InstructionVec.
No change to any hashx_cachegrind iai benchmarks
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generate_interp_1000x
Instructions: 219216169 (No change)
L1 Accesses: 278017243 (-0.000441%)
L2 Accesses: 1257 (+4389.286%)
RAM Accesses: 415 (-0.479616%)
Estimated Cycles: 278038053 (+0.001744%)
generate_interp_1000x_c
Instructions: 272748034 (No change)
L1 Accesses: 349932964 (No change)
L2 Accesses: 76 (-1.298701%)
RAM Accesses: 411 (+0.243902%)
Estimated Cycles: 349947729 (+0.000009%)
generate_compiled_1000x
Instructions: 256896028 (+0.175731%)
L1 Accesses: 342543838 (+0.131802%)
L2 Accesses: 149273 (-10.34924%)
RAM Accesses: 810 (-0.246305%)
Estimated Cycles: 343318553 (+0.106328%)
generate_compiled_1000x_c
Instructions: 281855218 (No change)
L1 Accesses: 362569035 (-0.000001%)
L2 Accesses: 88 (+1.149425%)
RAM Accesses: 473 (+0.211864%)
Estimated Cycles: 362586030 (+0.000010%)
interp_u64_hash_1000x
Instructions: 13450926 (No change)
L1 Accesses: 16622561 (+0.000024%)
L2 Accesses: 28 (No change)
RAM Accesses: 390 (-1.015228%)
Estimated Cycles: 16636351 (-0.000817%)
interp_8b_hash_1000x_c
Instructions: 8618541 (No change)
L1 Accesses: 12316160 (-0.000008%)
L2 Accesses: 80 (No change)
RAM Accesses: 433 (+0.231481%)
Estimated Cycles: 12331715 (+0.000276%)
compiled_u64_hash_100000x
Instructions: 87311792 (+0.000520%)
L1 Accesses: 94396598 (+0.000463%)
L2 Accesses: 215 (+2.380952%)
RAM Accesses: 774 (-0.641849%)
Estimated Cycles: 94424763 (+0.000304%)
compiled_8b_hash_100000x_c
Instructions: 91547640 (No change)
L1 Accesses: 98838166 (-0.000007%)
L2 Accesses: 137 (+3.007519%)
RAM Accesses: 488 (+0.618557%)
Estimated Cycles: 98855931 (+0.000119%)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
| |
Making a few comment tweaks suggested in review feedback.
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
|
|
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]>
|
