[isabelle-dev] performance regression for simp_all
Makarius
makarius at sketis.net
Sat Aug 13 01:07:52 CEST 2011
On Thu, 11 Aug 2011, Brian Huffman wrote:
> Recently I've been hacking on a bunch of proof scripts using the
> development version of Isabelle, and I noticed that when processing
> proof scripts, I often get a noticeable pause at uses of "simp_all". The
> same pause does not occur with Isabelle2011.
> lemma shows "True" and "True"
> by (simp, simp)
> (* 0.001s elapsed time, 0.000s cpu time, 0.000s GC time *)
>
> lemma shows "True" and "True"
> by simp_all
> (* 0.253s elapsed time, 0.004s cpu time, 0.000s GC time *)
This is indeed a bit slow, although it is not CPU time, only some latency
of the tty loop (which is inherently synchronous and thus slow).
http://isabelle.in.tum.de/repos/isabelle/rev/aaaa13e297dc improves startup
time of the worker thread farm significantly, and I've got real times in
the range of 0.003s -- 0.005s on my "old" machine from 2 years ago with
Proof General.
Really old machines with only 1 core should not experience any slowdown
from the parallel combinator, because multithreading is not enabled.
> The first bad revision is:
> changeset: 42372:6cca8d2a79ad
> user: wenzelm
> date: Sat Apr 16 23:41:25 2011 +0200
> summary: PARALLEL_GOALS for method "simp_all";
>
> http://isabelle.in.tum.de/repos/isabelle/rev/6cca8d2a79ad
>
> Was this change supposed to *improve* performance? Was the performance
> impact tested? Maybe the performance penalty only appears when
> interactively stepping through proofs, and not in batch mode?
Yes, it improves some sessions like HOL-Hoare_Parallel, probably also some
larger AFP ones, but we still don't have any old-style isatest statistics.
The worst-case overhead for batch mode should be neglible -- same for
Isabelle/jEdit which is closer to batch mode than PG tty mode.
Makarius
More information about the isabelle-dev
mailing list