-
Notifications
You must be signed in to change notification settings - Fork 273
Don't generate unnecessary fresh symbols for the GOTO trace #7021
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
base: develop
Are you sure you want to change the base?
Don't generate unnecessary fresh symbols for the GOTO trace #7021
Conversation
Codecov ReportBase: 78.26% // Head: 77.86% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #7021 +/- ##
===========================================
- Coverage 78.26% 77.86% -0.40%
===========================================
Files 1642 1569 -73
Lines 189830 180969 -8861
===========================================
- Hits 148568 140913 -7655
+ Misses 41262 40056 -1206
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
a0295ee
to
537ebd6
Compare
537ebd6
to
5d892f4
Compare
Avoid creating equalities over the postponed bitvector when the object literals trivially aren't equal, and directly encode bitwise equality when the object literals are trivially equal (and stop searching for a matching object). In all other cases, avoid unnecessary Tseitin variables to encode the postponed bitvector equality. When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 22409.9 seconds (4369.8 seconds speed-up); with Minisat, however, the hardest 49 proofs take 28616.7 instead of 28420.4 seconds (196.3 seconds slow-down). Across these benchmarks, 11.7% of variables and 12.8% of clauses are removed.
This was previously disabled as it appeared to degrade performance. New benchmarking, however, suggests considerable performance improvement: When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 24472.6 seconds (2307.1 seconds speed-up); with Minisat the hardest 49 proofs take 18541.2 instead of 28420.4 seconds (9879.2 seconds speed-up). Across these benchmarks, 1.0% of variables and 3.2% of clauses are removed.
This was previously disabled as it appeared to degrade performance. New benchmarking, however, suggests considerable performance improvement: When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 24472.6 seconds (2307.1 seconds speed-up); with Minisat the hardest 49 proofs take 18541.2 instead of 28420.4 seconds (9879.2 seconds speed-up). Across these benchmarks, 1.0% of variables and 3.2% of clauses are removed.
Avoid creating equalities over the postponed bitvector when the object literals trivially aren't equal, and directly encode bitwise equality when the object literals are trivially equal (and stop searching for a matching object). In all other cases, avoid unnecessary Tseitin variables to encode the postponed bitvector equality. When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 22409.9 seconds (4369.8 seconds speed-up); with Minisat, however, the hardest 49 proofs take 28616.7 instead of 28420.4 seconds (196.3 seconds slow-down). Across these benchmarks, 11.7% of variables and 12.8% of clauses are removed.
5d892f4
to
30c9bce
Compare
I love the performance graphs but please can we have the diagonal line so it is easy to see better / worse. |
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.
It is a little hard to follow how the changes implement what is described in the PR.
This was previously disabled as it appeared to degrade performance. New benchmarking, however, suggests considerable performance improvement: When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 24472.6 seconds (2307.1 seconds speed-up); with Minisat the hardest 49 proofs take 18541.2 instead of 28420.4 seconds (9879.2 seconds speed-up). Across these benchmarks, 1.0% of variables and 3.2% of clauses are removed.
This was previously disabled as it appeared to degrade performance. New benchmarking, however, suggests considerable performance improvement: When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 24472.6 seconds (2307.1 seconds speed-up); with Minisat the hardest 49 proofs take 18541.2 instead of 28420.4 seconds (9879.2 seconds speed-up). Across these benchmarks, 1.0% of variables and 3.2% of clauses are removed. INCLUDE_REDUNDANT_CLAUSES is not enabled: while this would yield a further speed-up of 1080.4 seconds with CaDiCaL, it slows down Minisat by 4440.6 seconds on the above benchmark set.
This was previously disabled as it appeared to degrade performance. New benchmarking, however, suggests considerable performance improvement: When running on various proofs done for AWS open-source projects, this changes the performance as follows (when comparing to diffblue#7021): with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26779.7 to 24472.6 seconds (2307.1 seconds speed-up); with Minisat the hardest 49 proofs take 18541.2 instead of 28420.4 seconds (9879.2 seconds speed-up). Across these benchmarks, 1.0% of variables and 3.2% of clauses are removed. INCLUDE_REDUNDANT_CLAUSES is not enabled: while this would yield a further speed-up of 1080.4 seconds with CaDiCaL, it slows down Minisat by 4440.6 seconds on the above benchmark set.
This is not a good idea. I'd first like to understand how the speedup works. And then I'd like to push that change into the decision procedure. The user of the decision procedure (here symex) shouldn't have to care about encoding tricks that are this low level. |
57d6542
to
81afb57
Compare
We can safely record the values of expressions by adding `expr == expr` as constraints in order to be able to fetch and display them in the GOTO trace. This was already being done for declarations. Introducing new symbols just adds unnecessary variables to the formula. When running on various proofs done for AWS open-source projects, this changes the performance as follows: with CaDiCaL as back-end, the total solver time for the hardest 46 proofs changes from 26546.5 to 26779.7 seconds (233.2 seconds slow-down); with Minisat, however, the hardest 49 proofs take 28420.4 instead of 32387.2 seconds (3966.8 seconds speed-up). Across these benchmarks, 1.7% of variables and 0.6% of clauses are removed.
81afb57
to
c7f67c6
Compare
We can safely record the values of expressions by adding
expr == expr
as constraints in order to be able to fetch and display them in the GOTO
trace. This was already being done for declarations. Introducing new
symbols just adds unnecessary variables to the formula.
When running on various proofs done for AWS open-source projects, this
changes the performance as follows: with CaDiCaL as back-end, the total
solver time for the hardest 46 proofs changes from 26546.5 to 26779.7
seconds (233.2 seconds slow-down); with Minisat, however, the hardest 49
proofs take 28420.4 instead of 32387.2 seconds (3966.8 seconds
speed-up). Across these benchmarks, 1.7% of variables and 0.6% of
clauses are removed.