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
#2359 reduced the number of bus receives from one per incoming connection to one per operation. I think we can reduce it further to one per machine.
Example
Suppose we have two operations:
operation foo<42> a, b -> c;
operation_bar<123> d -> e;
This currently compiles to two bus receives:
map(selectors, std::utils::force_bool);Constr::PhantomBusInteraction(-selectors[0],ID_FOO,[operation_id, a, b, c], selectors[0]);Constr::PhantomBusInteraction(-selectors[1],ID_BAR,[operation_id, d, e], selectors[1]);
Instead, we should be able to compile to:
map(selectors, std::utils::force_bool);
std::utils::force_bool(sum(selectors));Constr::PhantomBusInteraction(
-(selectors[0] + selectors[1]),ID_MACHINE,[
selectors[0]*42 + selectors[1]*123,
selectors[0]* a + selectors[1]* d,
selectors[0]* b + selectors[1]* e,
selectors[0]* c
],
selectors[0] + selectors[1]);// The operation_id column is now a bit redundant, could be removed.
operation_id = selectors[0]*42 + selectors[1]*123;
I am pretty sure that witgen wouldn't work for this, because it wouldn't be able to figure out which selector to set (but there is a unique assignment for a given operation ID!), but it would be sound.
Remarks
Note that this is possible even though the length of the parameter list is different. This works, because a fingerprint of the tuple $(a, b, c)$ is equal to the fingerprint of the tuple $(a, b, c, 0, 0, 0, ...)$ (you can pad any amount of zeros to the right), see Reverse fingerprint order #2405. As a result, the machine would receive a payload of a length corresponding to the largest operation. No change of the bus send is required, it can simply send a shorter payload.
I think the same trick would even be possible with a lookup or permutation: If you have two lookups / permutations connecting the same two machines, you can remove one. The RHS of the collapsed would look similar to the collapsed receive above.
We'd still have one selector per operation. Actually, because of this, the whole concept of an "operation ID" is redundant, as the example above shows.
The text was updated successfully, but these errors were encountered:
#2359 reduced the number of bus receives from one per incoming connection to one per operation. I think we can reduce it further to one per machine.
Example
Suppose we have two operations:
This currently compiles to two bus receives:
Instead, we should be able to compile to:
I am pretty sure that witgen wouldn't work for this, because it wouldn't be able to figure out which selector to set (but there is a unique assignment for a given operation ID!), but it would be sound.
Remarks
The text was updated successfully, but these errors were encountered: