You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the entire hash computation is done when the decoder makes its initialization request and all intermediate lookups required for the correctness of $b_{chip}$ are queued. When the decoder needs subsequent lookups (e.g. as it absorbs new operations during RESPAN or when the completes code blocks and needs the return hash), it sends a request, and they are dequeued and sent to the $b_{chip}$ bus.
Instead, it might be better to compute the lookups at the time they are needed.
The entire trace for a span block would still be computed as a part of the Hasher::hash_span_block(). But this method would not create any lookups. Instead, the HasherLookupContext::Start lookup would be created in Chiplets::hash_span_block(), and all other lookups would be created by Chiplets::absorb_span_batch() and Chiplets::read_hash_result() (though, we'd probably need to have a specialized version of this method for SPAN blocks).
There is a bit more complexity here as Decoder::respan() doesn't have access to the address of the batch being executed but I think it shouldn't be too complicated to provide this info to this method, and once it is there, other parts should be relatively straight-forward.
So, the Hasher would no longer be responsible for computing lookups, and that responsibility would move into hasher-related Chiplets methods.
For control blocks, the solution should be relatively simple:
At the time when control block execution ends, the decoder knows the address of the block (which it received from the hasher at the time when block hash is computed). We would need to update some method signatures in the decoder to propagate this info back to end_join_block(), end_split_block() etc. methods.
We can then pass this address into Chiplets::read_hash_result() method, and that should be enough to compute a lookup for the return value (addr for the lookup would be addr of the block + 7).
The text was updated successfully, but these errors were encountered:
Currently, the entire hash computation is done when the decoder makes its initialization request and all intermediate lookups required for the correctness of$b_{chip}$ are queued. When the decoder needs subsequent lookups (e.g. as it absorbs new operations during RESPAN or when the completes code blocks and needs the return hash), it sends a request, and they are dequeued and sent to the $b_{chip}$ bus.
Instead, it might be better to compute the lookups at the time they are needed.
Solution proposed by @bobbinth:
The entire trace for a span block would still be computed as a part of the
Hasher::hash_span_block()
. But this method would not create any lookups. Instead, theHasherLookupContext::Start
lookup would be created inChiplets::hash_span_block()
, and all other lookups would be created byChiplets::absorb_span_batch()
andChiplets::read_hash_result()
(though, we'd probably need to have a specialized version of this method for SPAN blocks).There is a bit more complexity here as
Decoder::respan()
doesn't have access to the address of the batch being executed but I think it shouldn't be too complicated to provide this info to this method, and once it is there, other parts should be relatively straight-forward.So, the
Hasher
would no longer be responsible for computing lookups, and that responsibility would move into hasher-related Chiplets methods.For control blocks, the solution should be relatively simple:
end_join_block()
,end_split_block()
etc. methods.Chiplets::read_hash_result()
method, and that should be enough to compute a lookup for the return value (addr for the lookup would be addr of the block + 7).The text was updated successfully, but these errors were encountered: