-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option for partitioned trace committment #336
Conversation
I wonder if we should define a new method on the pub trait Hasher {
fn merge_many(values: &[Self::Digest]) -> Self::Digest;
} |
I don't see a better solution. I will go with this unless there are any other remarks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Looks good! I left some comments inline.
Another thing I'm wondering is whether it is better to use partition_size
rather than num_partitions
after all. Or maybe we should use a combination of both - e.g., something like num_partitions
and min_partition_size
.
The motivation is that we actually compute commitments 3 times: main trace, auxiliary trace, and constraint evaluations. All of these may have different widths. Let's for example assume that we have
- main race: 72 columns
- aux trace: 7 columns (degree 2 extension)
- constraint evaluations: 8 columns (degree 2 extension)
With num_partitions = 4
, we'd split things into:
- main trace: 4 partitions with 18 columns each.
- aux trace: 3 partitions with 4 columns each + 1 partition with 2 columns
- constraint evaluations: 4 partitions with 4 columns each.
But if we have num_partitions = 4
and min_partition_size = 8
, we'd get the following:
- main trace: 4 partitions with 18 columns each.
- aux trace: 1 partition with 8 columns and 1 partition with 6 columns.
- constraint evaluations: 2 partitions with 8 columns each.
This seems like a slight better arrangement - but also not sure if the complexity is worth it.
We can also specify num_partitions
/partition_size
separately for each of the 3 components - but not sure if that's worth it either.
cc @TheMenko
This is how GPU code currently operates.
This wouldn't be a lot of work on the GPU side. The only thing is that we should measure the performance for these two cases. |
@irakliyk , I added a proposal to implement your idea of minimal partition size and it is included in the penultimate commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Looks good! I've added a few more comments. The main one is about potentially introducing PartitionOptions
struct.
I have also benchmarked the code to get an idea on the delta after this PR. The results are logical: Next
num_partitions=1 & min_partition_size=1
num_partitions=2 & min_partition_size=4
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thank you! I left a few more small comments inline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good! Thank you!
Addresses #335.
This still in draft as two points need to be clarified:
num_partitions
parts we need to hash all of them in order to get a final digest per row of the trace we are committing to. The issue is that directly hashing digests is not possible, or at least I couldn't see how to do it. One pass through the bytes representation but I am not sure this was the desired implementation. For now, the code just uses a naivemerge
in order to fold all the digests into one digest.num_partitions
equal to1
vs greater than1
is not very elegant but I couldn't see a way to merge handling of the two cases.