-
Notifications
You must be signed in to change notification settings - Fork 682
firstorder eauto
takes 90s and 1.8GB of RAM to find a one-line proof
#11352
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
Comments
Btw, not directly related, but might be of interest to other users: This is the first time I minimized an example using the bug minimizer by @JasonGross, and it was surprisingly easy. I just followed his instructions from this issue and the |
The atom unification procedure seems quadratic in the number of binders crossed. I'll see if I can make this any better. |
The bottom line of my examination of the problem is essentially that I have not the least idea of the expected semantics of I can provide a one-line patch that makes the instance in this PR three times as fast, although I cannot assess its correctness. I am afraid that fully solving the problem is tantamount to 1. clearly delimiting the intended semantics of |
Three times as fast would still be 30s, so we would still not use As a follow-up question: Would it be easy to provide a switch which allowed to replace the current atom unification procedure by simple syntactic unification (i.e. no unfolding)? In our development style, we always try to control manually what gets unfolded, so probably |
@samuelgruetter it would interesting to get some numbers on how well the latest CoqHammer works on the typical first order goals you encounter - which it should be particularly suited for thanks to backing from solvers like Vampire. Have you considered setting up some FOL goal benchmark suite for Coq (akin to Isabelle/HOL's Judgement Day)? In particular, the latest release of CoqHammer for Coq 8.10 finds a proof of the above goal in less than a second. Other FOL solvers for Coq that might be obsolete but could be benchmarked against |
Yes, a vote for that! IMHO integrating CoqHammer and SMTCoq better in Coq should be a priority for 2020. |
I've looked at coqhammer before and my understanding of it was that it works, in summary, like this:
From a quick I've also looked at SMTCoq and have put it on the list of things I want to try out in bedrock2, but more hasn't happened yet... 😉 |
@samuelgruetter I think your summary misses a few key steps in the process. From my reading of the code and the CoqHammer paper it's more like the following:
In contrast to Given these quite deep differences, I conjecture that naked |
Bas Spitters pointed out the following extended abstract on Coq and FOL solving which has some pointers on |
@ppedrot @samuelgruetter I just notice a weird behavior of firstorder when moving MetaCoq to a new term representation that now involves a sigma type with a boolean condition added: it becomes dead slow and eats up all memory. It seems the tactic is really trying to do too much. |
Most of my daily proof work is in first order logic, so one would expect that most of my proofs would just be something like
firstorder eauto
. However, in my experience,firstorder
only works on tiny projects, and as soon as there are too many unfoldable definitions involved in a proof,firstorder SomeTactic
becomes unusably slow (no matter what I put in forSomeTactic
).Therefore I spend a lot of time on writing simple manual proofs, and on maintaining various half-baked first-order solvers written in Ltac. This is unsatisfactory -- can Coq be better?
As a first step, I tried to minimize an example (as suggested by @JasonGross). It's from a file written by @andres-erbsen, but I observe similar behavior of
firstorder
in my own code too. I minimized it down to one stand-alone file of 687 lines. I hope that's small enough -- after all, an important "feature" of this example is that it's not too small, but I'd be happy to help minimizing it more.Here it is:
This goal can be solved with one line of manual Ltac, which runs in just a few milliseconds. Like this, the whole file can be processed using about 0.4GB of memory (measured using
/usr/bin/time -v coqc bugreport.v
, "Maximum resident set size").However, when I try to solve it with
firstorder eauto
, it takes about 90 seconds, and the whole file now needs about 2.2GB of memory, sofirstorder eauto
eats 1.8GB of memory.Coq version: master (3725487) and 8.9.0 as well
The text was updated successfully, but these errors were encountered: