You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related: [vst-user] mailing list thread, VST performance thread on Coq discoruse.
After upgrading our relatively large (43KLOC) C verification project from VST version 2.6 to 2.8 (along with ocaml and some others), we've encountered a major increase in compilation time: from 3.2 to 5.7 hours on single thread.
Following are the benchmarks of the same project before and after VST upgrade (with only minor fixes made).
VST 2.6
Opam switch
Using coq-config. NOTE: despite it being included in the base compiler, Coq was built without flambda support.
Can you provide more information about the funspec of the function ber_fetch_length ?
That might help me in replicating the problem so that I can fix it. For example, I conjectured that the problem was related to the very large number of addressable local variables (corresponding to the many lvar and data_at_ clauses in your current precondition), so on that basis I tried this experiment:
Within g, just at the forward_call to function f, there are then 12 lvars and 12 data_at_ in the precondition. But the forward_call takes just 2.163 seconds on my machine. So that does not seem to be the problem. I have also tried experiments with many temp vars, and experiments with many function parameters for the function f, and I also cannot replicate the slowdown.
(Of course, perhaps it goes fast on my machine because I have a core i7 processor...)
More measurements, shown here demonstrate that having 20 lvars, with the associated 20 data_at conjuncts, and functions with between 0 and 20 pointer parameters (with the corresponding 0 to 20 data_at conjuncts in the precondition), does not lead to exponential slowdown.
So, this issue report illustrates some performance problem in VST, but it's not simply the number of variables, or the number of function parameters, or the number of SEP conjuncts.
Related: [vst-user] mailing list thread, VST performance thread on Coq discoruse.
After upgrading our relatively large (43KLOC) C verification project from VST version 2.6 to 2.8 (along with ocaml and some others), we've encountered a major increase in compilation time: from 3.2 to 5.7 hours on single thread.
Following are the benchmarks of the same project before and after VST upgrade (with only minor fixes made).
VST 2.6
Opam switch
Using coq-config.
NOTE: despite it being included in the base compiler, Coq was built without flambda support.
Slowest lines
Based on
coq_makefile
'sTIMING=1
.Time+Memory per file
Based on
coq_makefile
'spretty-timed
.VST 2.8
Opam switch
Using coq-config.
Slowest lines
Based on
coq_makefile
'sTIMING=1
.Time+Memory per file
Based on
coq_makefile
'spretty-timed
.Sure, our code is not well optimzed, but the exact same tactic invocations are taking up to 4 times as long after the upgrade.
Furethermore, peak memory consumption of 15GiB is achieved in the same tactic invocation under both versions. Here are some details:
Peak memory tactic
Runninng
for goal corresponding to this line in C:
The text was updated successfully, but these errors were encountered: