Skip to content
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

Add unchecked serialization/deserialization #253

Merged
merged 1 commit into from
Aug 8, 2020
Merged

Conversation

Pratyush
Copy link
Member

@Pratyush Pratyush commented Aug 6, 2020

Add unchecked serialization and deserialization, for the case when one knows that the serialized output will be stored in a trusted location (for example: serialized and deserialized by the same machine).

cc @ChaitanyaKonda @iAmMichaelConnor, this might solve your use case in a cleaner way.

cc also @kobigurk @paberr

Copy link
Contributor

@paberr paberr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this is probably the cleaner way to do it. 👍
One remark though: The _unchecked variants are now incompatible with the _uncompressed methods for serialization/deserialization. The _unchecked implementations write the infinity bit explicitly into its own byte, while the _uncompressed code encodes it into the non-used bits.

Did you choose to use an explicit bool for performance reasons?
If yes, I think adding a note to the documentation would be good, indicating this difference.

@Pratyush
Copy link
Member Author

Pratyush commented Aug 7, 2020

Did you choose to use an explicit bool for performance reasons?

I did omit the flag handling for affine structs for performance reasons, but I should check that it actually makes a difference by benchmarking.

@kobigurk
Copy link
Contributor

kobigurk commented Aug 7, 2020

This is very useful! I actually might need something like this soon.
That said, I'm highly in favor of making it compatible with the normal decompression. @Pratyush do you think you're going to decide by benchmarking?

@Pratyush
Copy link
Member Author

Pratyush commented Aug 7, 2020

@kobigurk @paberr I think I'll just make it compatible with normal decompression, because I suspect most of the overhead is due to subgroup checks, and not due to bit manipulation. (I'm writing benchmarks right now to verify this)

@Pratyush
Copy link
Member Author

Pratyush commented Aug 8, 2020

I suspect most of the overhead is due to subgroup checks, and not due to bit manipulation.

Indeed, most of the overhead is due to the prime-group check.

@Pratyush Pratyush force-pushed the serde-unchecked branch 2 times, most recently from b0073f5 to 646a6e2 Compare August 8, 2020 01:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants