WalkSAT: Solving Boolean Satisfiability via Stochastic Search

Transcription

1 WalkSAT: Solving Boolean Satisfiability via Stochastic Search Connor Adsit Kevin Bradley December 10, 2014 Christian Heinrich Contents 1 Overview 1 2 Research Papers Efficient Implementations of SAT Local Search Parallelization of Stochastic Algorithm for Boolean Satisfiability on GPGPU Architecture Enhancing the Robustness/Efficiency of Local Search Algorithms for SAT Implementation Sequential Program Parallel Program Developer s Guide Usage Guide Data Strong Scaling Weak Scaling Future Work 16 6 Discussion 17 7 Work Breakdown 17 1 Overview Boolean satisfiability is a classic problem in computer science theory. It is best expressed as the question: Given a collection of literals that are combined via Boolean operations (AND, OR and NOT) to make a Boolean expression, 1

2 can we assign a truth value to each literal such that the expression evaluates to true. This problem, often abbreviated to SAT, is credited with being the first problem that was shown to be NP-Complete. This means that the best known algorithm to solve the problem operates in exponential time; in the worst case, it is just as efficient to enumerate exhaustively across the possible solution space, exponential in size, and see if the expression evaluates to true, which we can do in polynomial time. In particular, we focus our attention on a subset of SAT problems, known as CNF-SAT, where the Boolean expressions are in Conjunctive Normal Form. This means that the expression is organized into clauses, in which literals, either a variable or its negation, are ORed together and all clauses are ANDed together In order for a CNF-SAT expression to be satisfiable, every one of its clauses must be satisfied with a given truth assignment. There has been considerable research to craft efficient algorithms that can find actual solutions if they exist. Our focus lies not with these algorithms, but creating a stochastic local search algorithm that estimates an answer. Instead of implementing the popular DPLL algorithm, we instead randomly generate a truth assignment and then apply a small change to it. We repeat this process while the changes improve the number of clauses satisfied. When we re done iterating, we have a potential candidate for a solution. Since this process estimates a solution, repeating it over and over again with additional random assignments increases the likelihood that we are able to find an actual solution. 2 Research Papers 2.1 Efficient Implementations of SAT Local Search This paper analyzes variable selection and variable flipping techniques that are utilized with various local search SAT algorithms. The paper provides an overview of what occurs at each step of an iteration in a SAT local search algorithm. In general there are two parts, deciding which variable to flip, and flipping the decided variable. Namely the paper discusses the techniques of WalkSAT and GSAT (two local search satisfiability algorithms) along with a couple of some additional options for differing heuristics and data structures to use for implementation. The paper also provides some results and analysis from testing these various different ideas. The paper makes the novel contributions of providing details, mathematical analysis and numerical measurements evaluating and comparing various different techniques used in local search SAT algorithms. Additionally they introduce (and prove the efficiency) of a new variable flipping technique they named watch2. By keeping track of additional information (a second satisfied literal for each clause) they reduce the effect cost of updating clauses (and the associated information that needs to be updated) on frequent transition of the 2-1 case. This is the case in which flipping a literal changes the number of satisfied literals in a clause from 2 to 1. Their analysis showed this was an often 2

3 occurring transition, came up with a way to improve this transition (at the cost of making others more expensive) and then analyzed the performance of this. This paper provided us with a better understanding of the time complexity implications of various different means of variable selection and updating. This aided us in understanding that in the case of weak scaling in order to increase our problem size we cannot merely increase the number of clauses, the number of literals, or a simplistic combination of both while achieving a specified sizeup in computational complexity. For our weak scaling we then decided to increase the number of iterations the hill climbing was attempting thus creating a fairly ideal computational sizeup. Furthermore, the paper demonstrated the efficiency and effectiveness of different variable selection techniques for variable flipping. It was shown that WalkSATs variable selection technique (selecting a random clause then deciding which variable to flip) is far more efficient than deciding which variable to flip based on GSAT or SAPS. Deciding which variable to flip in these algorithm takes into account all variables in the equation and not just those within a particular clause. They further show that in cases of a large number of literals the cost associated with selecting the variable to flip in these algorithms can dominate the run time. Due to this noticeable difference we decided to continue along the WalkSAT implementation for this reduced time complexity (opposed to using a different variable selection technique). 2.2 Parallelization of Stochastic Algorithm for Boolean Satisfiability on GPGPU Architecture The paper Parallelization of Stochastic Algorithm for Boolean Satisfiability on GPGPU Architecture discusses a new parallel implementation of WalkSAT intended for GPGPU architectures, named cwsat. The issue cwsat is intended to address is improving the performance of local search algorithms for satisfiability problems, in this case WalkSAT, in order to maximize its performance advantage over other potential solutions. They specifically implement cwsat in the CUDA environment, to take advantage of the potentially massive number of threads they are able to utilize in said environment. The paper summarizes the difference between the two major categories of SAT solving algorithms, DPLL and local search algorithms like WalkSAT, explains the potential for local search algorithms, and the common heuristics used. These are heuristics are Best, Tabu, Novelty, Novelty+, Rnovelty and Rnovelty+. The standard implementation of WalkSAT, like ours, only utilizes the Best heuristic, meaning that based on some probability p, the algorithm will either pick a random literal in the unsatisfied clause to flip, or it will follow the heuristic meaning it will select the literal to flip which causes the least amount of currently satisfied clauses to become unsatisfied. Their GPGPU parallel implementation cwsat drops several of these heuristics, including the random, instead opting to only implement Best, Tabu, Novelty+, and Rnovelty+. They utilize these heuristics by dividing the threads into sets of four threads, with each set of threads assigned its own random model of the problem, however each thread carried out its own WalkSAT computation 3

4 utilizing a specific heuristic based on its thread ID, meaning that each thread in the thread group performed its own WalkSAT over the same model, but each with a different heuristic. Once a thread finds a satisfiable model, all threads stop and that model is reported back to the host. However, it is also possible for cwsat to fail to find a satisfiable model in the time allotted, much like normal WalkSAT. Using this structure allows cwsat to best scale to maximum number of threads available, based on the amount of memory required to store the problem for each thread and the number of cores on the device. For example, they tested cwsat versus four different WalkSAT implementations, each using a different heuristic that cwsat was also using, over two hundred SAT benchmarks from the SAT11 competition. This resulted in improvements over WalkSAT in terms of both runtime and the success rate for problems with a satisfiable solution, over all heuristics. The biggest increase was over WalkSAT using the standard Best heuristic, with a 98 percent decrease in runtime versus WalkSAT using that heuristic, though this decreased to only a 33 percent decrease in runtime when compared to WalkSat using the Novelty+ heuristic, which was the best performing. It also saw an increase in successfully finding a satisfiable model in all but one problem, putting it above both Best and Tabu, equal to Rnovelty+ and one behind Novelty+, making it a very reasonable potential solution to the problem of increasing performance over WalkSAT. While we ultimately decided not to implement a GPGPU solution like cwsat, instead opting to implement a multicore version of standard WalkSAT, this paper did provide insight into possible implementations for the future. While this paper did focus on cwsat, it showcased more potential future directions for our program beyond just the possibility of a GPGPU version, specifically in its analysis of the different possible heuristics we could test in the future. 2.3 Enhancing the Robustness/Efficiency of Local Search Algorithms for SAT This paper discusses a few heuristics used to fine tune the efficiency of WalkSAT and rates their effectiveness on certain types of problems. Of the heuristics discussed, we thought that only two were interesting. The first is the traditional approach, which is what we have implemented in our program: with a certain probability p, we flip either a random variable in a random clause or with probability 1 p, we pick a variable in a random clause such that flipping it changes the fewest clauses that already evaluate to true to false (which is known as the break count). The other interesting heuristic, known as Novelty, builds upon this notion of minimizing the break counts. In cases where more than one variable has the same break count, we pick the variable that was least recently changed. Additionally, the paper suggested that it could be beneficial to keep track of any dependencies between literals. Depending on the structure of the overall expression, the value of certain literals may depend on a single literal. In some cases, they may even be forced to have the same values. Knowing these ahead of time can limit the search space of the WalkSAT algorithm, but we decided 4

5 not to incorporate this into our implementation because we believed that it would add additional overhead to the sequential portion of our algorithm, since the best time to discover these dependencies would be as we were reading in the boolean expression from the file. We were concerned that adding in the additional computation would increase the sequential portion enough to limit the efficiency gains of parallelization and felt that such a feature would be better suited for a DPLL approach rather than a WalkSAT approach. At the end of the paper, the author discussed how the standard WalkSAT algorithm performed in comparison to other WalkSAT implementations with different variable choice heuristics on Latin Square problems (where a matrix is a latin square if each row and column are permutations on the same set of numbers) and the planning logistic problem. The measurement of performance was not done by examining the work, but rather the accuracy of the problem, which we did not value as much as the efficiency, so for the most part, we disregarded this part of the paper. Additionally, we were not able to easily find Latin Square or logistics planning problems in.dimacs format, which lead us to widely ignore the data presented. 3 Implementation 3.1 Sequential Program For our implementation, we represented clauses as a list of literals, which would be ORed together, and additionally we kept track of the current truth value of the evaluation of each clause based on the current truth assignment as a bit vector, indexed by the clause s position in the input file. Truth assignments are bit vectors, where each literal (indexed starting at 1) truth value (0 for false, 1 for true) is indexed by the literal s integer assignment. We perform N walks in sequence. In each walk, we perform as many as nsteps, stopping early if we find a solution or cannot progress to a better assignment by flipping the truth assignment of a single literally. For each possible step, we pick with probability 0.2, a literal in a random broken clause that causes the fewest already true clauses to become false and with probability 0.8, a random literal in a random broken clause. If the result of flipping whichever literal we pick is better than our current result, in that more clauses evaluate to true or fewer clauses were originally true became false and more clauses originally false became true, then we take a future step from the new assignment. 3.2 Parallel Program Our parallel program uses the same data structures and same walking algorithm as our sequential program. Because each walk starts from a randomly generated truth assignment, there are no sequential dependencies between walks. We take advantage of this in our parallel program by splitting the total number of walks amongst the number of threads given to the program. We assumed that we did 5

6 not need to include any sort of load balancing because we can not determine how much work each walk performs, since we start from a randomly generated truth assignment. 3.3 Developer s Guide All the required source files will be in the deliverables.jar file. To compile, first make sure that the pj2 library is in the path and that you have extracted all files out of the supplied jar. To compile the files, simply run: javac *.java If desired, you may wish to change the probabilities that determine which method our implementation of WalkSAT uses to decide which variable assignment to flip. It is by default set to choose the assignment with the lowest breakcount in a random clause with a chance of 20%. We determine probability by using modular arithmatic. We perform a modulus by the final variable P MOD and check to see that the result is less than P REM to determine if the breakcount minimization is used to pick the variable (which means that initially we set P MOD to 5 and P REM equal to 0). 3.4 Usage Guide To run the sequential version, run: java pj2 WalkSATSeq <N> <nstep> <seed> <infile> where <N> is the number of walks to perform, <nstep> is the maximum number of steps to take in a walk, <seed> is a long value that seeds the random number generator and <infile> is the.dimacs input file used to create the Boolean expression. To run the parallel version, execute: java pj2 threads=<nt> WalkSATSmp <N> <nstep> <seed> <infile> where <N>, <nstep>, <seed> and <infile> are the same as the sequential version and <NT> is the desired number of threads. The input files are in the form of.dimacs, automatically generated from It is assumed that these files have a particular structure. They begin with a single line of comments, denoted by a c. This line is ignored. The following line contains information about the problem, that it is in CNF form, followed by the number of variables and the number of clauses. Each subsequent line is a clause, containing integers that correspond to literals. If the integer is negative, then it corresponds to a negated literal. These lines are delimited by a zero followed by a newline character. We have included many files in the zip which you can use to test our program. 6

7 K RT (msec) Speedup Efficiency Figure 1: Problem 1 K RT (msec) Speedup Efficiency Data 4.1 Strong Scaling Figure 2: Problem 2 For testing our implementations strong scaling, we randomly generated 5 different satisfiability problems using Toughsat.appspot.com. Each problem generated was a 3CNF problem of the Random k-sat problem type, with a ten to one clause to variable ratio as this created the most difficult problems, starting with ten variables. So problem one had ten variables and one hundred clauses, K RT (msec) Speedup Efficiency Figure 3: Problem 3 7

8 K RT (msec) Speedup Efficiency Figure 4: Problem 4 K RT (msec) Speedup Efficiency Figure 5: Problem 5 problem two had twenty and two hundred, etc. until problem five with fifty variables and five hundred clauses. Each problem was run with one hundred iterations and one thousand flips, scaling the number of cores from one to eight. Our program ended up demonstrating slightly less than ideal strong scaling performance, with the worst performance being for problems one and the best for problem five, with the scaling improving slightly with each problem. The program also demonstrated a fairly steep drop in speedup and efficiency between using two and eight cores, with around four to five cores seemingly being the breaking point after which the speed up increases far more slowly, resulting in a drop in efficiency. All of which indicates some form of sequential dependency, with the likely culprit being the input read in, as this isnt parallelized. While reading in the input would take longer with each problem as the problem size increased, the computation time would increase more, thus allowing our parallelization to exert more influence over the run time, leading to the increase in speedup and efficiency. This is perhaps best demonstrated by running the fifth problem on two cores, which results in a speedup of leading to efficiency slightly greater than one. The issue of poor scaling past four to five cores is also lessened as the problem size increase, leading to an efficiency of on eight cores for problem five, versus on eight cores for problem one. By that number of cores for problem one, the program has already started to run up against the time spent reading in the input, leading to only slight decreases in 8

9 Figure 6: Strong Scaling: Running Time vs. Number of Cores 9

10 Figure 7: Strong Scaling: Efficiency vs. Number of Cores 10

11 runtime between six, seven and eight cores, with almost no change in runtime between seven and eight cores. Whereas the results from running problem five over six, seven and eight cores actually saw an increase in efficiency between six and seven cores, and a further increase between seven and eight cores. Similar jumps in performance occurred for problems three and four, but less consistently, which may also be caused by the nature of the algorithm, as the variable flipped can either be random or whichever results in the lowest break count, but these two choices result in a different amount of computation, with random being the less computationally intensive, so there is going to be more variation depending on which method was used more often. 11

12 K Iterations RT (msec) Sizeup Efficiency Figure 8: Problem 1, 10 Literals, 100 Clauses, flips K Iterations RT (msec) Sizeup Efficiency Figure 9: Problem 2, 20 Literals, 200 Clauses, flips 4.2 Weak Scaling For our weak scaling we utilized 5 different satisfiability problems each randomly generated. The first problem was an equation in CNF which had 10 literals and 100 constants, the second problem had 20 literals and 200 constants, and so on. This was to maintain a constant to literal ratio of 10 across our problems. Each of these problems was run with the parameter that for each iteration variable flips were to be made (unless a solution was found). Instead of trying to increase the problem size for each of our scaling examples since this is K Iterations RT (msec) Sizeup Efficiency Figure 10: Problem 3, 30 Literals, 300 Clauses, flips 12

13 K Iterations RT (msec) Sizeup Efficiency Figure 11: Problem 4, 40 Literals, 400 Clauses, flips K Iterations RT (msec) Sizeup Efficiency Figure 12: Problem 5, 50 Literals, 500 Clauses, flips non-trivial for boolean satisfiability to find an equation that is precisely twice as computationally complex we simply increased the number of iterations we would perform the hill climbing corresponding to the number of cores we were utilizing. For instance with 1 core we used the parameter of 10 iterations while on 8 cores we would use a parameter for 80 iterations which would properly increase the problem size as desired. Our program showed non-ideal weak scaling but in our problems the weak scaling efficiency never dropped below.85 which is fairly good. It is worth noting the sequential dependency of reading in the initial input file which is not parallelized and is a contributing factor to this non ideal scaling. Additionally, as our problems increased in size (from 10 literals 100 clauses to 50 literals 500 clauses) our efficiency increased. This is likely due to the lower overhead of reading the file. While reading the file of a larger problem will take a little more time, the computation of the problem is so much larger that this sequential time is dominated by our parallel running time yielding a greater efficiency in our larger problems. Another peculiarity is that our efficiency would drop (as expected), increase (unexpected), then drop again (expected) as the number of cores increased. For example in problem 5, our efficiency on 2 cores was.970, on 3 cores was.975 and on 4 cores was.953. This abnormality is probably caused by the nondeterminism associated with our algorithm. Since deciding which variable to flip 13

14 Figure 13: Weak Scaling: Running Time vs. Number of Cores 14

15 Figure 14: Weak Scaling: Efficiency vs. Number of Cores 15

16 in a clause can be random (very inexpensive) or based on the literal resulting in the lowest breakcount (more expensive) the runtime of our algorithm can vary. While in one instance it might have made several variable flips based on finding the literal with the lowest breakcount, in another instance it might have made several variable flips from randomly selecting a variable within the clause. The second instance would result in a lower runtime potentially so much so that the small sequential file reading overhead is completely eclipsed. 5 Future Work One possible extension of this project would be to develop a cluster program in addition to our multicore program. With this cluster program we could experiment on Tardis and analyze our weak and strong scaling performance there. We could then generate a set of problems and try to determine a threshold of when it would (or would not) be more advantageous to use the cluster version. In practice this cluster version would likely be best for a large scale problem in which it is important to arrive at the closest possible solution. Namely, a large problem with a large number of iterations (hill climbing attempts) being performed. In the same spirit another extension would be to find and experiment with different, more realistic satisfiability problems. For this we could find some common satisfiability problems or a suite of them which are used to benchmark other algorithms. By testing our implementation against these would be be able to compare and contrast our performance with that of other implementations on an apples to apples level. Another extension would be to extend our program to be able to work on weighted satisfiability problems. This would mean that each of our clauses in our CNF has a particular weight associated with it. The change being that if it is case that the problem is not satisfiable the goal is to find the literal assignments which would result in the maximum achieved clause value. The achieved clause value would be the summation of the weights of the satisfied clauses in a particular literal assignment configuration. One final change that could be made given more time would be to evolve our program into a multicore automatic theorem prover. Automatic theorem proving is one of the many applications of boolean satisfiability. This would require changing our program to accept a different type of input (a representation of the theorem to prove or disprove) and boiling down this problem into the underlying boolean satisfiability problem or problems which need to be solved. We could then apply our implementation of WalkSAT to solve these in order to prove or disprove the given particular theorem. 16

17 6 Discussion We learned about Boolean Satisfiability, its applications, and specifically the WalkSAT algorithm, and the implementation of WalkSAT in parallel. This included that WalkSATs performance in parallel depends heavily on the size of the problem given to it. If the problem is too small, the performance increase as cores are added is rather inefficient, due to the performance limitations caused by reading in the problem, meaning that parallel implementations of WalkSAT are far more effective when dealing with larger problems, and somewhat inefficient for smaller ones. We also learned about some alternative methods and implementations from our research papers, including DPLL, an alternative to WalkSAT which was covered by another group, as well as GPGPU implementations of WalkSAT, in the form of cwsat. 7 Work Breakdown Connor did the majority of the development for the sequential and parallel versions of the program. He also covered the paper Enhancing the Robustness/Efficiency of Local Search Algorithms for SAT. Christian did all the Strong Scaling testing, and covered the paper Parallelization of stochastic algorithm for boolean satisfiability on GPGPU architecture. Kevin did all the Weak Scaling testing, and covered the paper Efficient Implementations of SAT Local Search. The presentations and other sections of the paper were worked on in collaboration. References [1] A. Fukunaga, Efficient implementations of SAT local search, pp , [Online]. Available: [2] S. Nimnon, M. Phadoongsidhi, and N. Utamaphethai, Parallelization of stochastic algorithm for boolean satisfiability on GPGPU architecture, pp. 1 4, [Online]. Available: [3] D. Habet, Enhancing the robustness/efficiencey of local search algorithms for sat, pp , [Online]. Available: 17