-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Use a static constant table for small ecmult WINDOW_G sizes. #614
Conversation
I only tested this very minimally, so please don't immediately dump it on an embedded device and waste 4 hours troubleshooting. Test on a desktop first. :P |
Concept ACK Tested that Benchmarks (SiFive Unleashed RV64GC, no endomorphism, default 1Ghz clock speed, gcc 9.0.1,
So from Another run with
This is just about true: the size of |
@apoelstra Thoughts on how this should interact with the single allocation change? |
Concept ACK
How is this related to scratch spaces? |
@real-or-random oops should have really directed at #566 just had 'single allocation' on the brain. When we do single allocation / no-allocation API's we'll need to leave the memory for this table out from the allocation. (which is also why I want to do this PR after merging those, as I don't want to disrupt them.) |
Rebased, fixed endomorphism support, ifdefed out secp256k1_ecmult_odd_multiples_table_storage_var. TODO: Update configure output, include a comment explaining how the constants are generated, and decide on how big to support. 6 is sounding pretty good based on llanwj's data. Plus some assorted ifdef cleanup. @laanwj Any interest in getting the actual binary size without this PR, with it and size 2 and size 6? on RV? |
It does not hurt but this style of just hardcoding the constants is somewhat inconsistent with the one by gen_context. I like the approach here more because it's much simpler; gen_context creates a lot of complexity in the build system. Maybe we should also add a pre-generated file with gen_context constants to the repo in the future. |
TODO: Update configure output, include a comment explaining how the constants are generated, and decide on how big to support. Better handling for exhaustive tests? I'm unsure about gen_context the big reason that we don't ship a static table is because it's enormous (as in comparable to the size of the codebase enormous). This issue doesn't really arise with window_g. We should probably change signing to use #546 and then we could have equivalent performance with a much smaller table, and then it might be less of a consideration. |
Yep okay, I didn't see that point. |
For discussion for now: this need to be reworked some to play nicely with #600.
When WINDOW_G is small there is no reason to not pre-compute it: on almost all embedded devices flash is much 'cheaper' than ram, pre-computation can be burdensomely slow, and the code to do the precomputation might actually be larger than the table (I haven't checked). We wouldn't want to put a 1.3 MB table in the source/library but a 1024 byte one hardly seems like a concern.
This is relevant to #603 @laanwj