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

Improve proof speed of invntt_layer() #411

Closed
wants to merge 1 commit into from

Conversation

rod-chapman
Copy link
Contributor

For this proof we tell CBMC to remove constraints that are not in the cone of influcence of the proof obligations using the --slice-formula option.

Experiment shows this reduces proof time for this subprogram from about 40s to about 12s on a developer's laptop.

Total proof time (using 8 CPU cores on M1 MacBook Pro)
before: 3m 46s
after: 3m 7s

All tests OK
All proofs OK
lint OK

@hanno-becker
Copy link
Contributor

@rod-chapman The speed gain seems well within the variance of runtime, isn't it? If so, I'd prefer not to add the flag.

@rod-chapman
Copy link
Contributor Author

Well... I see "variance of runtime" in the CI as a bug in the CI system. Adding --slice-formula consistently saves 22s of CPU time of this one proof for me, every time. Impact on a multi-core machine running all the proofs will vary, of course.

For this proof we tell CBMC to remove constraints that are not in the cone of
influcence of the proof obligations using the "--slice-formula" option.

Experiment shows this reduces proof time for this subprogram from about
40s to about 12s on a developer's laptop.

Signed-off-by: Rod Chapman <[email protected]>
@rod-chapman rod-chapman force-pushed the invntt_layer_proof_speed branch from 12f9b68 to 777a962 Compare November 18, 2024 11:31
@mkannwischer
Copy link
Contributor

I've measured this on my i7-1360P for 3 runs each
(time MLKEM_K=3 make result in the invntt_layer dir)

main (75f52dc): 14s, 12s, 12s
this PR (777a962): 12s, 14s, 12s

This does not seem to be a bottleneck for me and the PR does not change anything. Am I doing something wrong?

@mkannwischer
Copy link
Contributor

Looking at the CI

I also see 13-14 seconds on Graviton 3.
Is this really that much slower on Apple M1?

@rod-chapman
Copy link
Contributor Author

I am checking. In short: it's a problem with Z3 on macOS, where run time and memory consumption are an order of magnitude more than on Graviton/Linux and Intel/Linux. Even within the NIX shell, the same version of Z3 running on the same input files actually differs in behaviour on all 3 platforms.

@rod-chapman
Copy link
Contributor Author

I have opened Z3Prover/z3#7457 to report this problem with Z3. On short: it diverges on macOS for reasons as yet unknown. Suggest we close this issue here.

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