| Commit message (Collapse) | Author | Age | |
|---|---|---|---|
| * | Update headers. |  Maxime Dénès | 2015-01-12 |
| | | |||
| * | STM: primitives to snapshot a .vi while in interactive mode |  Enrico Tassi | 2014-10-13 |
| | | |||
| * | STM: code restructured to reuse task queue for tactics | Enrico Tassi | 2014-08-05 |
| | | |||
| * | remoteCounter: backup/restore | Enrico Tassi | 2014-02-26 |
| | | | | | | When you resume the compilation of a .vi file, you want to avoid collisions on fresh names. | ||
| * | Paral-ITP: cleanup of command line flags and more conservative default | Enrico Tassi | 2014-01-05 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | -async-proofs off the system behaves as in 8.4 -async-proofs lazy proofs are delayed (when possible) but never processed in parallel -async-proofs on proofs are processed in parallel (when possible). The number of workers is 1, can be changed with -async-proofs-j. Extra options to the worker process can be given with -async-proofs-worker-flags. The default for batch compilation used to be "lazy", now it is "off". The "lazy" default was there to test the machinery, but it makes very little sense in a batch scenario. If you process things sequentially, you'd better do them immediately instead of accumulating everything in memory until the end of the file and only then force all lazy computations. The default for -ideslave was and still is "on". It becomes dynamically "lazy" on a per task (proof) basis if the worker dies badly. Note that by passing "-async-proofs on" to coqc one can produce a .vo exploiting multiple workers. But this is rarely profitable given that master-to-worker communication is inefficient (i.e. it really depends on the size of proofs v.s. size of system state). | ||
| * | Universe counters on slaves are in sync with master |  gareuselesinge | 2013-08-20 |
| Simple framework for remote counters. The slaves ask the master for a fresh value. On the master the thread manager answers with a bunch of fresh values (so that further requests can be immediately satisfied). Remote counters are guarded with a mutex on the master, because all slave managers as well as the master thread can access the counter at the same time. I know the name sucks. These counters are remote for the slaves, and local for the master. I'm open to suggestions... git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16713 85f007b7-540e-0410-9357-904b9bb8a0f7 | |||
 |
index : coq | |
| the Coq proof assistant |
| aboutsummaryrefslogtreecommitdiffhomepage |