lazy clause exchange policy for parallel sat solversclause exchange in parallel solvers. . . . . ....

.Introduction

. .Clause exchange in parallel solvers

. . . . . .Lazy clause exchange

. . . .Experiments

.Conclusion

Lazy clause exchange policyfor parallel SAT solvers

Gilles Audemard CRIL, Lens, France

Laurent Simon Labri, Bordeaux, France

ANR "Investments for the future"

CPU (ANR-10-IDEX-03-02)

SAT (A FLOC Conference) – Vienna July 2014, 15th 1/21

.Introduction



. . . .Experiments

.Conclusion

Today’s Itinerary

..

Introduction

Clause exchange in parallel solvers

Lazy clause exchange

Experiments

Conclusion


.Introduction



. . . .Experiments

.Conclusion

Today’s Itinerary

..

Introduction SAT ingredients



Experiments

Conclusion


.Introduction



. . . .Experiments

.Conclusion

Ingredients of an efficient SAT solver

..

..Preprocessing(and inprocessing)

.

Restarting

.

Branching

.

Conflict Analysis

.

Clause DatabaseCleaning


.Introduction



. . . .Experiments

.Conclusion


..

..Preprocessing (and inprocessing).

Restarting

.

Branching

.

Conflict Analysis

.



.Introduction



. . . .Experiments

.Conclusion


..

..Preprocessing (and inprocessing).

Restarting

.

Branching

.

Conflict Analysis

.

Clause DatabaseAdditionsDeletions


.Introduction



. . . .Experiments

.Conclusion

Today’s Itinerary

..

Introduction

Clause exchange in parallel solvers From sequential solvers to parallel solvers


Experiments

Conclusion


.Introduction



. . . .Experiments

.Conclusion

Many Cores

Multi-core architecture, cloud ⇒ design of parallel solversDifferent strategies

Divide and conquer Explicitly splits search w.r.t. assignments

Portfolio algorithmsEach thread: its own solver and the whole formula

Rely on orthogonal searchesParallel solver

communication: learnt clauses All threads working on the same proof

..

Solver2(Σ)

.

Solver1(Σ)

. Solver3(Σ).

Solver4(Σ)


.Introduction



. . . .Experiments

.Conclusion

Many Cores, Many more problems

Sharing clauses in parallel has many drawbacks

..Preprocessing(and inprocessing)

.

Restarting

.

Branching

.

Conflict Analysis

.


Imported clauses can be bad (noise, wrong way, . . . )Imported clauses can be subsumed / uselessImported clauses can dominate learnt clausesEach thread has to manage many more clausesMany side effects on all core components

Currently: Clauses are sent as soon as they are learnt, plus:manysat 1.0: size ≤ 8manysat 1.1: dynamically adjust the thresholdplingeling: size ≤ 30 and LBD ≤ 8Penelope: LBD ≤ 8 (PSM allows more clauses exchanges)


.Introduction



. . . .Experiments

.Conclusion

Today’s Itinerary

..

Introduction


Lazy clause exchange Experiments: Useless Clauses and More Useful Clauses Lazy Exportation of Clauses Lazy Importation of Clauses

Experiments

Conclusion


.Introduction



. . . .Experiments

.Conclusion

Many useless clauses even in single engine solvers

..

10000

100000

1e+06

1e+07

10000 100000 1e+06 1e+07

#Use

less

Cla

uses

in fi

nal U

NSA

T Pr

oof

#Conflicts

GlucoseGlucose No reduce DBL.R. Glucose (m=0.42)

L.R. Glucose No reduce DB (m=0.55)y=x

x-axis : Number of conflictsy-axis : Useless clauses in final proof (UNSAT formulas)


.Introduction



. . . .Experiments

.Conclusion

How many times clauses are seen in conflicts

..

1000

10000

100000

1e+06

1e+07

1000 10000 100000 1e+06 1e+07

# C

laus

es s

een

at le

ast Z

tim

es

# Conflicts

Seen Z=1 timeL.R. Seen 1 time (m=0.91)

Seen Z=2 timesL.R. Seen 2 times (m=0.34)



x-axis: Number of conflictsy-axis: Number of clauses seen at least Z times


.Introduction



. . . .Experiments

.Conclusion

Conclusions from the experiments

..

A lot of useless clauses even in a single engine!

In parallel, this situation will be even worse!

Why sending a clause that is even not locally interesting?

We will consider clauses seen 2-times (only 34% of learnt clauses) Already filter out the majority of clauses

How to efficiently detect them?Is there a window of recent clauses to check?

Can we check only recent learnt clauses (and save time)?


.Introduction



. . . .Experiments

.Conclusion

Learnt and Directly Reused Clauses

..

1000

10000

100000

1e+06

1e+07

1000 10000 100000 1e+06 1e+07

# D

irect

ly R

euse

d Le

arnt

Cla

uses

# Conflicts

Directly Reused Learnt Clausey=x

Linear Regression (m=0.41)

x-axis: Number of imported clauses (sum over 8 threads)y-axis: Number of promoted clauses (sum over 8 threads)

91% of clauses seen at least 1 time. Only 41% are immediately seen. SAT (A FLOC Conference) – Vienna July 2014, 15th 12/21

.Introduction



. . . .Experiments

.Conclusion

Lazy Exportation of Clauses

..

Clauses are sent during conflict analysis

We only export clauses when seen 2 times in conflict analysis and:Clauses with LBD ≤ median(LBD) and size ≤ average(SIZE)

Limits updated at each clause database cleaning

Unary clauses and very glue clauses are immediately sent

Lazy because we wait to have a good chance of local interest beforeconsidering sending it


.Introduction



. . . .Experiments

.Conclusion

Lazy Importation of Clauses

.. Problem of clauses importations:

can destroy the current search effortclauses can be redundantmany clauses to manage (performance impact)

How to be sure an imported clause is interesting before considering it?

Idea: put it in probation

Imported clauses are put in a 1-Watched schemeWill be promoted to a 2-Watched scheme only if found empty

Other AdvantagesLess efforts for propagationsCan be seen as a dynamic Freezing/Reactivating strategyClauses are imported with a local (and correct) LBD value


.Introduction



. . . .Experiments

.Conclusion

Today’s Itinerary

..

Introduction



Experiments Solver’s Behavior Solver’s Performances

Conclusion


.Introduction



. . . .Experiments

.Conclusion

How many promotions?

..

1000

10000

100000

1e+06

1e+07

1000 10000 100000 1e+06 1e+07

# Pr

omot

ed C

laus

es (s

um o

ver t

he 8

thre

ads)

# Imported Clauses (sum over the 8 threads)

Promoted ClausesL.R. Promoted Clauses (m=0.10)

y=x

x-axis: Number of imported clauses (sum over 8 threads)y-axis: Number of promoted clauses (sum over 8 threads)


.Introduction



. . . .Experiments

.Conclusion

Implementation details

..

Solvers have many restarts Import clauses at decision level 0 only

Imported clauses (1-Watched) database have its own deletion strategy Limits the impact of importation on the solver

(Gory) Details of Glucose-Syrup in the contest:One solver is created, then clonedNumber of solvers adjusted to fit into 40% of allowed memoryWhen approaching the max memory allowed, switch to Panic Mode:Almost Constant Memory consumption modeNo tuning of cores strategies. Only the “French’s Flair”.

Idea: as few parameters changes as possible


.Introduction



. . . .Experiments

.Conclusion

Syrup versus Plingeling on SAT11 benchmarks

..

1

10

100

1000

1 10 100 1000

Plingeling(99 SAT + 109 UNSAT)

Syrup(98 SAT + 130 UNSAT)

SATUNSAT

Syrup: 228 instances solved - 98 SAT / 130 UNSAT !!Plingeling: 208 instances solved - 99 SAT / 109 UNSAT


.Introduction



. . . .Experiments

.Conclusion

Syrup versus Plingeling on SAT13 benchmarks

..

1

10

100

1000

1 10 100 1000

Plingeling(125 SAT + 110 UNSAT)

Syrup(105 SAT + 99 UNSAT)

SATUNSAT

Syrup : 204 instances solved - 105 SAT / 99 UNSATPlingeling : 235 instances solved - 125 SAT / 110 UNSAT !!


.Introduction



. . . .Experiments

.Conclusion

Today’s Itinerary

..

Introduction



Experiments

Conclusion


.Introduction



. . . .Experiments

.Conclusion

Conclusion

A simple, efficient, more semantic way to exchange clauses between cores

Parallel Glucose seems very efficient on non crypto problems (like Glucose)

Special thanks to:Marijn Heule

For helping us debugging the unstable competition versionDaniel le Berre

For fruitful discussions at the Banff Workshop

Please wait to download a stable-cleaned-improved version of glucose syrup


lazy clause exchange policy for parallel sat solversclause exchange in parallel solvers. . . . . ....

Documents