<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/hashx/src/compiler.rs, branch main</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=main</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=main'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-08-07T15:28:36Z</updated>
<entry>
<title>Switch Cargo.toml files to edition 2024.</title>
<updated>2025-08-07T15:28:36Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-08-06T01:19:58Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=77b0de43b8c67cdb81befe0680a3df43b6ad37bc'/>
<id>urn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc</id>
<content type='text'>
First, run

```
git grep -l "^edition =" |
    xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```

Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.

Third, run cargo fmt again.
</content>
</entry>
<entry>
<title>hashx: Cleanup around Instruction and NUM_INSTRUCTIONS</title>
<updated>2023-08-25T20:14:24Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-08-25T20:11:47Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=2cb50d1be35a4a6623ff318fcf8ac2620521bb1f'/>
<id>urn:sha1:2cb50d1be35a4a6623ff318fcf8ac2620521bb1f</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Rustfmt</title>
<updated>2023-08-25T17:12:56Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-23T11:00:15Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=cb151df6ab0a9fb28135b7a50e973e2c75c4a6fd'/>
<id>urn:sha1:cb151df6ab0a9fb28135b7a50e973e2c75c4a6fd</id>
<content type='text'>
</content>
</entry>
<entry>
<title>RFC: hashx: Make Architecture::compile take an array ref</title>
<updated>2023-08-25T17:12:56Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-23T10:11:11Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=f789f0914b65391b293aac75ab86720028ffa88f'/>
<id>urn:sha1:f789f0914b65391b293aac75ab86720028ffa88f</id>
<content type='text'>
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%)
</content>
</entry>
<entry>
<title>hashx: New approach to avoid memcpy in Program</title>
<updated>2023-08-21T22:27:28Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-08-15T21:35:05Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ceacd5c98808ed8ecd91d6645be3ad32ce606ad0'/>
<id>urn:sha1:ceacd5c98808ed8ecd91d6645be3ad32ce606ad0</id>
<content type='text'>
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&lt;Instruction&gt;
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 (&gt;1024b) memcpy are now
totally gone in the generate-interp test.

Signed-off-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>tor-hspow, equix, hashx: Comment tweaks</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-07-20T01:25:04Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=4affddaa0866955eafaea1c1ce6c3b240f206782'/>
<id>urn:sha1:4affddaa0866955eafaea1c1ce6c3b240f206782</id>
<content type='text'>
Making a few comment tweaks suggested in review feedback.

Signed-off-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Reimplement HashX in Rust</title>
<updated>2023-07-27T14:20:06Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T21:59:46Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a8756f2bce9f0dba8e445baae82aab90aa9ad096'/>
<id>urn:sha1:a8756f2bce9f0dba8e445baae82aab90aa9ad096</id>
<content type='text'>
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 &lt;beth@torproject.org&gt;
</content>
</entry>
</feed>
