Use u64 trie iteration tokens#52
Conversation
Implements the answer the iter-token note in the TrieNode trait already sketched: the token is a node-local cursor, so it never needs to encode a whole path, and 64 bits are enough. The ByteNode stops caching the remaining mask word inside the token (the source of the 128-bit requirement); it keeps only one more than the last byte returned and recomputes the next set bit from its own mask (next_iter_byte_from, four masked trailing_zeros probes, still O(1) per step). All other node types already used small counters. iter_token_for_path semantics are unchanged (resume strictly after the given byte; the 63/127/191/255 word-edge cases land identically through the word advance), pinned by a new mask-word-boundary test. Consumers treat tokens as opaque, so the swap is type-level for them; ReadZipperCore shrinks from 144 to 128 bytes (measured on both trees), and each ancestor stack entry loses 8 bytes of padding.
|
Local best-of-3 on suggested benchmarks. Do you want more benchmarks @luketpeterson ? |
|
We're going to explore this a little further: this can potentially be optimized further still (based on making the zipper smaller). |
…Seems to save 10% or so in dense byte iteration Style and comment fixes
|
I wasn't able to reproduce the speedup from the original change but I'm confident it's real; probably a difference in memory architectures. However I could see some regressions when there was a high proportion of ByteNodes (e.g. the superdense benchmarks) I ended up implementing the change proposed in the comment this PR deleted (which was different from what the original change did) and it seems to have made every number go up (improve). However, given the difference in my benchmark results, @Adam-Vandervorst should probably give the benchmarks another run before merging. |
|
Also, to the question of "Can ByteMask iterator benefit", the answer is not really. In the case where there are a bunch of iterators being stored, i.e. the new bytemask_iter_recursive_stack benchmark, there is a benefit. But it's outweighed by a regression in the common case and additional API complexity. So that option is there is we need it. But not worth it for now. |
Summary
Answers the question the
new_iter_tokendoc comment already asks: thetoken is a node-local cursor, so it never needs to encode a whole path, and
64 bits are enough. The
ByteNodestops caching the remaining mask wordinside the token — the source of the 128-bit requirement — and keeps only
one more than the last byte returned, recomputing the next set bit from its
own mask (
next_iter_byte_from: a maskedtrailing_zerosprobe across atmost four words, still O(1) per step). Every other node type already used
small counters, so this is purely a type change for them.
iter_token_for_pathsemantics are unchanged (resume strictly after thegiven byte); the word-edge cases (63/64, 127/128, 191/192, 255) are pinned by
a new test. Consumers (the zippers, cursors, merkleization, viz) treat
tokens as opaque, so the swap is type-level there.
Result
ReadZipperCoreshrinks from 144 to 128 bytes (measured on both this branchand
master), and each ancestor-stack entry loses 8 bytes of padding.Interleaved A/B against
master(two reps each side):superdense_k_path-7..-8%,
sparse_iter-23..-47%,binary_iterup to -53%, no regressedcell in either bench. The resume-strictly-after contract is also modeled in
Alloy (
fac27_iter_tokenin a separate verification repo), UNSAT in scope.Test plan
cargo test --release --lib(661/0, matches themasterbaseline)cargo miri teston the new boundary test and the touched dense-node testscargo test --release --doc(7/0)cargo bench --bench superdense_keys / sparse_keys / binary_keys -- iter