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

Performance difference between solvers #7134

Closed
rafaelsamenezes opened this issue Feb 21, 2024 · 4 comments
Closed

Performance difference between solvers #7134

rafaelsamenezes opened this issue Feb 21, 2024 · 4 comments

Comments

@rafaelsamenezes
Copy link

At ESBMC we noticed a benchmark with a huge difference between exporting SMT2 from Boolector and Z3 (esbmc/esbmc#1698). Specifically, Boolector took 5s and I could not reach a solution with Z3 under 5min. Also, extracting the boolector formula and feeding it to Z3 gave the same performance (<5s).

Could you please advise whether there is a configuration to make Z3 have a similar performance?
z3-flat.txt
btor-formula.txt

@NikolajBjorner
Copy link
Contributor

no configuration at the moment.
It is all pre-processing.
You have a huge set of stores into something that has no effect.
Boolector implements pre-processing that Z3 does not have at the moment.

It may be as simple as detecting that

   F[(store A I E)] is equi-satisfiable to F[A]  

where F is a formula context, A an array, I an index, and E an element.

For your formula I are all constant indices, E are disjoint extracts into a bit-vector that isn't used elsewhere.
Thus, E are essentially non-aliased nonces. E is therefore unconstrained. A is also unconstrained.
This would allow the simplification.

@rafaelsamenezes
Copy link
Author

Thanks for the feedback,

I will implement this pre-processing at ESBMC level then and check if it gives us the same performance boost then.

NikolajBjorner added a commit that referenced this issue Feb 21, 2024
Signed-off-by: Nikolaj Bjorner <nbjorner@microsoft.com>
@NikolajBjorner
Copy link
Contributor

ehm, this was not as complicated. Z3 has an inefficiency when handling large stores with constant offsets.
I added a throttle to avoid this.
The rewrite is direct because at the top level you use a select with a constant address into an array of constant addresses.
It now takes a few seconds to complete.

@lucasccordeiro
Copy link

Many thanks, @NikolajBjorner.

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

No branches or pull requests

3 participants