Скачать презентацию Using Parallelism to Improve Theorem Prover Interactivity David Скачать презентацию Using Parallelism to Improve Theorem Prover Interactivity David

3314b2fd5db3098bad6be4252032d1e5.ppt

  • Количество слайдов: 29

Using Parallelism to Improve Theorem Prover Interactivity David L. Rager May 17, 2010 Committee Using Parallelism to Improve Theorem Prover Interactivity David L. Rager May 17, 2010 Committee Members: Warren A Hunt Jr. (Chair), Matt Kaufmann, J Strother Moore, James C Browne, Emmett Witchel

Project Goal Ø Reduce the latency between when a user submits a conjecture and Project Goal Ø Reduce the latency between when a user submits a conjecture and when the user receives useful feedback concerning that conjecture’s provability 2

Outline Ø Introduction l l Ø Ø The Automated Proof Process – the Waterfall Outline Ø Introduction l l Ø Ø The Automated Proof Process – the Waterfall The ways ACL 2 currently uses parallelism Research Contributions Key Steps l l Removing sequential dependencies Introducing Parallelism into the Proof Process • • • l l Ø Adding futures to the underlying implementation language Adding parallelism abstractions to the logic Using parallelism in the waterfall Managing output Managing user interrupts Evaluating the Soundness and Performance of our Approach 3

The Proof Process Ø Named “the waterfall” Ø We hope to parallelize the application The Proof Process Ø Named “the waterfall” Ø We hope to parallelize the application of all but the induction heuristic 4

The Proof Process Each proof obligation that is not the original goal that needs The Proof Process Each proof obligation that is not the original goal that needs to go through the waterfall is called a subgoal Ø We parallelize at the subgoal level because: Ø l Highest level of granularity available without considering parallelizing the proofs of theorems themselves • Parallelizing the proofs of goals is thought to be much less useful l l Already attempted parallelizing the rewriter without much practical gains The waterfall is mostly functional in nature, whereas the code above the waterfall (which includes the induction code) tends to have more side-effects 5

Current Use of Parallelism in ACL 2 Ø Process-level parallelism l l GNU’s “make Current Use of Parallelism in ACL 2 Ø Process-level parallelism l l GNU’s “make –j#” and cert. pl Certifies the regression suite in parallel Ø Plet/pargs/pand/por l l User level parallelism Useful for improving performance of proofs by simulation 6

Research Contributions Ø Maintain Interactivity l Continue to support ACL 2 users’ ability to Research Contributions Ø Maintain Interactivity l Continue to support ACL 2 users’ ability to use the prover despite parallel execution in its proof process Ø Mechanisms for Early Feedback l l Provide feedback to theorem prover user asap Could result in super-linear speedup 7

Research Contributions Ø Improve Support for Lisp-Level Programming l Ø Interface that unifies multi-threading Research Contributions Ø Improve Support for Lisp-Level Programming l Ø Interface that unifies multi-threading libraries Provide Parallelism Abstractions l Enrich the built-in theory with primitives that allow parallel execution • spec-mv-let, a better plet, etc. Ø Evaluate our Approach l Determine the usefulness of parallelizing a modern semi-automatic theorem prover at the subgoal level • Speedup • How we present non-deterministic output 8

Key Steps Create version of ACL 2 without sequential dependencies (e. g. , the Key Steps Create version of ACL 2 without sequential dependencies (e. g. , the modification of state and pspv) in the main proof process (the waterfall) Ø Introduce raw Lisp primitives and ACL 2 abstractions necessary to evaluate the waterfall in parallel Ø Reincorporate the interactive portion of the waterfall (output and interrupts) Ø Evaluate the soundness and performance of our approach Ø 9

Removing Sequential Dependencies from the Waterfall Ø State-based Challenges l State is a special Removing Sequential Dependencies from the Waterfall Ø State-based Challenges l State is a special type of variable in ACL 2 • Used when performing I/O, when performing system calls, etc. • Contains the “logical story” for these side-effects l ACL 2 restricts the use of state in the following two ways • ACL 2 restricts the name “state” from being used a variable anywhere that it doesn’t represent this one particular instance • ACL 2 requires that if state is modified, that the modified state be returned as part of the return value l So, if we remove the modification of state from the waterfall, we will know that the waterfall is (mostly) side-effect free. • Allows us to more easily find the big “gotchas” (e. g. , I/O) 10

Removing Sequential Dependencies from the Waterfall Ø State-based Solutions l l Preliminary step: remove Removing Sequential Dependencies from the Waterfall Ø State-based Solutions l l Preliminary step: remove I/O from the waterfall Disable proof techniques that require modifying state (e. g. , clause processors and computed hints) • Skip the proofs of libraries that require those techniques l l Results in skipping about 7% of the regression suite Our current thoughts are that we can reinstate most of these techniques as demand occurs 11

Removing Sequential Dependencies from the Waterfall Ø PSPV-based Challenges l l The Prover SPecial Removing Sequential Dependencies from the Waterfall Ø PSPV-based Challenges l l The Prover SPecial Variables (PSPV) data container acts as an accumulator for changes to variables that would be global, if ACL 2 were written in a non-functional manner. Need to find a way to combine these changes that does not negatively affect the soundness or performance of ACL 2 12

Removing Sequential Dependencies from the Waterfall Ø PSPV-based Solutions l l l If we Removing Sequential Dependencies from the Waterfall Ø PSPV-based Solutions l l l If we know how to combine the changes between the two proof steps, do so. Otherwise, terminate the latter proof step and restart it with the intermediate PSPV value Results in a computation exactly the same as the serial computation, without a need to combine PSPVs 13

Component 2: Introducing Parallelism Ø Adding futures to the underlying implementation language (Lisp) Ø Component 2: Introducing Parallelism Ø Adding futures to the underlying implementation language (Lisp) Ø Adding parallelism abstractions to the logic (ACL 2’s logic) Ø Managing output Ø Managing user interrupts 14

Adding Futures to the Underlying Implementation Language Ø Create functions for spawning, reading, and Adding Futures to the Underlying Implementation Language Ø Create functions for spawning, reading, and terminating the evaluation of futures l l l (future x) : : X -> Future-structure (future-read x) : : Future-structure -> X (future-abort x) : : Future-structure -> C Ø Relies upon our multi-threading interface that unifies CCL and SBCL features 15

Adding Parallelism Abstractions to the Logic Ø Modify plet to support multiple values and Adding Parallelism Abstractions to the Logic Ø Modify plet to support multiple values and speculative evaluation l l l Give the ACL 2 user a means to specify that a variable is unused in a particular expression Therefore, once evaluation enters a branch with such a specified branch, plet can terminate the evaluation of the unnecessary variable values Already defined plet differently in raw Lisp and the ACL 2 logic • This is an enhancement of what we already created [Rager 2008, Rager and Hunt 2009] l Example usage: (plet (((x y) (mv 3 4)) ((q r) (mv 8 9))) (if (equal q 8) (check-vars-unused-and-kill (x y) (+ q r)) (+ x y q r))) 16

Adding Parallelism Abstractions to the Logic By using this enhanced version of plet, we Adding Parallelism Abstractions to the Logic By using this enhanced version of plet, we can create new abstractions, e. g. spec-mv-let Ø Spec-mv-let automatically performs the check that certain variables are unused and automatically terminates unnecessary computations Ø Example annotated usage: Ø (spec-mv-let (x y) ; ; speculatively evaluate (mv 3 4) (mv-let (q r) (mv 8 9) (if (equal q 8) ; ; the speculative evaluation is irrelevant, return ; ; a value that doesn’t use those results (+ q r) ; ; the speculative evaluation is useful, return a ; ; value that uses those results (+ x y q r)))) 17

Component 3: Managing Interactivity Ø Original Goal: maintain output consistent between serial and parallel Component 3: Managing Interactivity Ø Original Goal: maintain output consistent between serial and parallel proofs of subgoals l l Store the output in a data structure and signal when the next piece of output is ready for printing I believe this to be feasible, but we would like to do more 18

Managing Output Ø New Goal: print meaningful output as it becomes available l Print Managing Output Ø New Goal: print meaningful output as it becomes available l Print the proof checkpoints as soon as they are computed • There is usually a very minimal amount of checkpoint output compared to the amount of output that occurs with a full proof attempt’s narrative l Users suggest that in the relatively rare case that a user wants to see the full narrative, that they would likely be satisfied with replaying the proof in a serial manner. 19

Managing Output Ø It is unclear what type of interface changes will be necessary Managing Output Ø It is unclear what type of interface changes will be necessary to accommodate nondeterministic output Ø An investigation into such accommodations is a planned part of this work Ø An example of one potential interface follows 20

21 21

Managing User Interrupts When a user aborts a proof, all subgoal computations will be Managing User Interrupts When a user aborts a proof, all subgoal computations will be gracefully terminated and the parallelism state of ACL 2 will be reset to its initial state Ø When a user attempts to debug a proof: Ø l l l Automatically interrupt and pause other threads Automatically order those threads to resume evaluation Users also have access to these functions that pause and resume subgoal computations 22

Component 4: Evaluating our Approach Ø Soundness Ø Performance 23 Component 4: Evaluating our Approach Ø Soundness Ø Performance 23

Evaluating Soundness A large subset of the regression suite (93%) will be able to Evaluating Soundness A large subset of the regression suite (93%) will be able to pass with parallelism enabled Ø We rely on our strategic development and use of macros as our main source of credibility Ø Insert assertions that check for unexpected changes in the program’s state. Ø This branch of the build will be tuned for interactivity. Those desiring the assurance level of non-parallel ACL 2 can run the serial version. Ø 24

Evaluating Performance Ø Goal: Reduce the latency between when a user submits a conjecture Evaluating Performance Ø Goal: Reduce the latency between when a user submits a conjecture and when the user receives useful feedback concerning that conjecture’s provability Ø We do not try to improve the performance of proof attempts that take < 1 second 25

Evaluating Performance We are not concerned with proof attempts that take less than a Evaluating Performance We are not concerned with proof attempts that take less than a second to compute, because anything between 0. 10 seconds and 1. 0 seconds feels the same to a user. Ø Example performance result for certifying one of the ACL 2 libraries: Ø Summary for making books/ordinal-addition. cert: Average sequential time was: 6. 22 s Average parallel time was: 5. 09 s Sequential minimum was: 6. 12 s Parallel minimum was: 4. 87 s Of 10 iterations, the parallel version was faster than the sequential version 10 times. 26

What We’ve Done so Far Ø Removed the modification of state and output from What We’ve Done so Far Ø Removed the modification of state and output from the waterfall Ø Modified Lisp library and ACL 2 to permit parallel evaluation of the waterfall Ø Run some preliminary performance benchmarks 27

What’s Left Ø Reintroducing output in a helpful way Ø Improving performance Ø Evaluating What’s Left Ø Reintroducing output in a helpful way Ø Improving performance Ø Evaluating our solution 28

Outline Ø Introduction l l Ø Ø The Automated Proof Process – the Waterfall Outline Ø Introduction l l Ø Ø The Automated Proof Process – the Waterfall The ways ACL 2 currently uses parallelism Research Contributions Key Steps l l Removing sequential dependencies Introducing Parallelism into the Proof Process • • • l l Ø Adding futures to the underlying implementation language Adding parallelism abstractions to the logic Using parallelism in the waterfall Managing output Managing user interrupts Evaluating the Soundness and Performance of our Approach 29