Proof and Program Parallelism with ACL2(P)
Total Page:16
File Type:pdf, Size:1020Kb
Proof and Program Parallelism with ACL2(p) David L. Rager Dept. of Computer Science, University of Texas at Austin [email protected] 1 Introduction This talk serves as a guide to using parallelism within ACL2. We (1) introduce a new parallelism prim- itive that ACL2 programmers can use to program in parallel, and (2) show the interface that ACL2(p) offers for enabling and controlling proof parallelism within the primary ACL2 proof process, the ACL2 Waterfall. The material presented here is also described in the ACL2 documentation [2] and our ELS paper [6]. Further related reading can be found in an earlier ACL2 workshop paper [3], Rager’s Master’s Thesis [4], and our 2009 ILC paper [5]. Whenever we write “see :doc <topic>”, we are referring the reader to documentation topic <topic> inside the ACL2 manual [2]. 1.1 Defining ACL2(p) We define ACL2(p) in two ways. First, the abstract notion is that ACL2(p) is the version of ACL2 that supports user-level parallel programming and parallel execution of the waterfall. Second, the technical definition is that ACL2(p) is ACL2 compiled with the acl2-par Lisp feature enabled (see :doc compiling- acl2p for how to perform such a compilation). ACL2(p) comes with the following disclaimer (from :doc parallelism): We hope and expect that every evaluation result is correctly computed by ACL2(p), and that every formula proved using ACL2(p) is a theorem of the ACL2 logic (and in fact is provable using ACL2). However, we do not guarantee these properties. Since ACL2(p) is intended to be an aid in efficient evaluation and proof development, we focus less on ironclad soundness and more on providing an efficient and working implementation. Nevertheless, if you encounter a case where ACL2(p) computes an incorrect result, or produces a proof where ACL2 fails to do so (and this failure is not discussed in :doc unsupported-waterfall- parallelism-features), please notify the implementors. 2 Spec-mv-let We designed the shape and features of spec-mv-let to support parallelizing the ACL2 waterfall. The user can think of spec-mv-let as a speculative version of mv?-let. (In ordinary ACL2, the seman- tics agree with this description but without speculative or parallel evaluation.) Spec-mv-let has the following general form, taken from and further detailed in :doc spec-mv-let. To appear in EPTCS. 2 Proof and Program Parallelism with ACL2(p) (spec-mv-let (v1 ... vn) ; bind distinct variables <spec> ; evaluate speculatively; return n values (mv-let (w1 ... wk) ; bind distinct variables <eager> ; evaluate eagerly (if <test> ; use results from <spec> if true <typical-case> ; may mention v1 ... vn <abort-case>))) ; does not mention v1 ... vn 2.1 Performance of Spec-mv-let Here we show a definition for the parallel version of the Fibonacci function that uses spec-mv-let. As reported in our ELS paper, a definition similar to this one has provided a speedup factor of 7.75 when evaluating (pfib 45) on a machine with eight cpu cores [6]. (defun pfib (x) (if (< x 33) (fib x) (spec-mv-let (a) (pfib (- x 1)) (mv-let (b) (pfib (- x 2)) (if t (+ a b) "speculative result is always needed"))))) 3 Using Parallelism within the ACL2 Proof Process We now discuss how to enable and manage the use of parallelism within the primary ACL2 proof process, more commonly known as the ACL2 waterfall. 3.1 Enabling Waterfall Parallelism The main method for enabling waterfall parallelism is macro set-waterfall-parallelism. The fol- lowing quote from :doc set-waterfall-parallelism describes the different options for waterfall parallelism. Set-waterfall-parallelism accepts an argument that specifies how much parallelism should be allowed when executing the waterfall. The possible arguments are nil, :full, :top-level, :resource-based, :resource-and-timing-based, and :pseudo-parallel. :Resource-based is the recommended setting for ACL2(p). We next outline some charac- teristics for each setting. 1. A value of nil indicates that ACL2(p) should never prove subgoals in parallel. 2. A value of :full indicates that ACL2(p) should always prove independent subgoals in parallel. 3. A value of :top-level indicates that ACL2(p) should prove each of the top-level subgoals in parallel but otherwise prove subgoals in a serial manner. This mode is useful when the user knows that there are enough top-level subgoals, many of which David L. Rager 3 take a non-trivial amount of time to be proved, such that proving them in parallel will result in a useful reduction in overall proof time. 4. A value of :resource-based indicates that ACL2(p) should use its built-in heuristics to determine whether CPU core resources are available for parallel execution. Note that ACL2(p) does not hook into the operating system to determine the workload on the machine. ACL2(p) works off the assumption that it is the only process using significant CPU resources, and it optimizes the amount of parallelism based on the number of CPU cores in the system. (Note that ACL2(p) knows how to obtain the number of CPU cores from the operating system in CCL, but that, in SBCL and in LispWorks, a constant is used instead). 5. During the first proof attempt of a given conjecture, a value of :resource-and-timing-based results in the same behavior as with :resource-based. However, on subsequent proof attempts, the time it took to prove each subgoal will be considered when deciding whether to parallelize execution. If a particular theorem’s proof is already achieving satisfactory speedup via :resource-based parallelism, there is no reason to try this setting. However, if the user wishes to experiment, the :resource-and-timing-based setting may improve performance. Note that since the initial run does not have the subgoal proof times available, this mode will never be better than the :resource-based setting for non- interactive theorem proving. 6. A value of :pseudo-parallel results in using the parallel waterfall code, but with serial execution. This setting is useful for debugging the code base that supports par- allel execution of the waterfall. For example, you may wish to use this mode if you are an “ACL2 Hacker” who would like to see comprehensible output from tracing (see :doc trace$) the @par versions of the waterfall functions. 3.2 Controlling Waterfall Output The amount of output that ACL2 provides could be quite overwhelming when printed in the interleaved manner that comes with parallel execution. Even if ACL2(p) printed the output one subgoal at a time, with the non-deterministic order, the user would likely grow frustrated. As such, when the user enables waterfall parallelism, by default, ACL2(p) will print a much smaller subset of the output than it would if it were executing serially. There are three options for calling the macro that sets up waterfall printing, set-waterfall-printing: :full, :limited, and :very-limited. A setting of :very-limited, along with enabling gag-mode (perhaps with a call of (set-gag-mode t), is the recommended set- ting for ACL2(p). The following quote from :doc set-waterfall-printing explains each of these settings. 1. A value of :full is intended to print the same output as in serial mode. This output will be interleaved and often unreadable unless the waterfall-parallelism mode is one of nil or :pseudo-parallel. 2. A value of :limited omits most of the output that occurs in the serial version of the waterfall. Instead, the proof attempt prints proof checkpoints, similar to (but still distinct from) gag-mode. As applies to much of the parallelism extension, the presen- tation of these checkpoints is still under development, and feedback concerning them is welcome. The value of :limited also prints messages that indicate which subgoal 4 Proof and Program Parallelism with ACL2(p) Figure 1: Performance of ACL2 Proofs Proof Case Min Max Avg Speedup Embarrass serial 36.49 36.53 36.50 par 4.58 4.61 4.60 7.93 JVM-2A serial 229.79 242.40 231.14 par 34.42 39.42 35.51 6.51 Measure-2 serial 175.99 179.93 176.53 par 47.07 53.71 50.01 3.53 Measure-3 serial 86.63 86.85 86.73 par 24.24 25.36 24.90 3.48 is currently being proved. Naturally, these subgoal numbers can appear out of order, because their subgoals can be proved in parallel. For a discussion of how subgoals pushed for induction with waterfall parallelism enabled are named, see :doc parallel- pushing-of-subgoals-for-induction. 3. A value of :very-limited is treated the same as :limited, except that instead of printing subgoal numbers, the proof attempt prints a period (‘.’) each time it starts a new subgoal. 3.2.1 Performance of Waterfall Parallelism As presented in the ELS paper, Figure 1 shows the speedup for four proofs with waterfall parallelism set to :resource-based [6]. The first proof is a toy proof that we designed to be embarrassingly parallel and test the ideal speedup of our system. The proof named “JVM-2A” is about a JVM model constructed in ACL2. The third and fourth proofs are related to proving the termination of Takeuchi’s Tarai function [1]. These proofs are not intended to be representative of all ACL2 proofs. Parallelism does not improve the performance of many ACL2 proofs, and it might even slow down some proofs. Investigating these issues is part of our future work. 4 Conclusion We present the parallelism primitive spec-mv-let, which allows significant speedup of ACL2 programs with little extra annotation in the code.